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ABSTRACT 


A  mathematical  model  of  a  computer  system  for  multi-user  data 
base  management  is  presented.  Rules  of  cooperation,  a  scheduling 
strategy,  and  a  safety  algorithm  are  shown  to  provide  harmonious 
cooperation  among  processes  while  preventing  conflict,  deadlock,  and 
permanent  blocking.  Throughout  the  development,  the  discussion  is 
related  to  a  set  of  COBOL  programs  operating  on  a  collection  of 
COBOL  files. 
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PREFACE 


The  work  reported  herein  was  performed  under  Project  671A, 
Multi-User  Data  Base  Management  task,  for  which  the  project  leaders 
were  Mrs.  Judith  A.  Clapp  (MITRE)  and  Dr.  John  B.  Goodenough  (ESD) . 

The  starting  point  can  most  easily  be  identified  by  reference 
to  the  works  of  Habermann^)  and  Silver^)  -  that  is,  I  set  out  to 
see  what  could  be  done  to  achieve  multi-user  data  sharing  if  I 
assumed  the  general  approach  of  the  referenced  works. 

In  (1)  Dr.  Habermann  established  in  1967  a  mathematical  model  of 
a  system  of  cooperating  abstract  machines;  to  my  knowledge,  there  has 
been  no  significant  refinement  of  the  model  nor  replacement  for  the 
model  since  that  time.  The  latter  remark  should  be  understood  in  the 
context  "given  the  same  general  problem,  information,  and  desired 
properties."  Other  deadlock-free  resource  sharing  models  have  tended 
to  go  in  the  direction  of  refinement  by  requiring  more  information 
about  a  process  (abstract  machine) — this  leads  to  the  potential  for 
performance  improvement  but  does  not,  in  my  opinion,  provide  a  new 
significant  model.  One  problem  with  the  model,  as  reported  by  Dr. 
Habermann  in  his  popularized  version^)  of  his  doctoral  thesis,  has 
been  pointed  out  by  Holt  in  (3) ,  wherein  he  offers  a  solution  to  the 
problem  of  permanent  blocking  of  a  process. 

A  principal  part  of  the  model is  a  multi-dimensional  resource 
sharing  discipline  (multi-dimensional  loan  office  model) ,  wherein 
resources  are  partitioned  into  a  finite  number  of  equivalence  classes 
with  a  finite  number  of  indistinguishable  members  in  each  class.  It 
is  interesting  to  note  that  a  good  deal  of  the  theoretical  work  appear¬ 
ing  in  (1)  with  respect  to  the  abstract  machines  (such  as  the  notions 
of  "coupled  machines",  "system  of  abstract  machines",  "task-flow 
diagram",  "feed-back  task",  "cooperation  in  conversational  mode", 
"hierarchical  system",  "the  difficult  case  that  what  is  to  be  considered 
as  a  borrowed  coin,  may  in  its  turn  become  a  customer  of  the  loan- 
office",  and  others)  seems  to  have  been  largely  ignored  in  the  litera¬ 
ture,  although  these  notions  are  a  significant  part  of  the  original 
work. (1> 

In  any  case  it  is  quite  clear  that  direct  application  of  Dr. 
Habermann* s  model  to  the  sharing  of  data  leads  to  an  artificial 
methodology,  for  we  do  not  generally  have  the  case  that  a  data  base 
may  be  partitioned  into  equivalence  classes  of  indistinguishable 
objects.  This  is  certainly  no  criticism  of  Dr.  Habermann*s  work — 
clearly,  there  was  not  the  intention  on  his  part  that  the  data  sharing 
problem  would  be  solved  by  his  model. 
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(2) 

The  influence  of  Dr.  Habermann’s  work  on  the  work  of  Mr.  Silver 
is  apparent.  The  motivation  for  the  choice  of  binary  relation  between 
elements  of  the  data  base  may  well  have  derived  from  the  discussion  of 
hierarchical  structure  by  Dr.  Habermann , in  which  he  defines  a 
hierarchical  system  of  abstract  machines  to  be  one  in  which  the  collec¬ 
tion  of  classes  of  equivalent  machines  does  not  contain  any  loops. 

The  graph-theoretic  approach  adopted  by  Mr.  Silver  has  the  nice  property 
that  circuits  in  digraphs  correspond  nicely  to  loops  in  the  collection 
of  classes  of  equivalent  machines  in  Dr.  Habermann’s  work.  It  is  not 
surprising  that  the  loop-free  digraph  in  Mr.  Silver* s  model  represents 
a  safe  state  of  the  system. 

In  the  present  work,  the  notion  of  binary  relation  among  elements 
of  the  data  base  has  been  borrowed  from  Mr.  Silver’s  work  (no  such 
relation  among  elements  of  equivalence  classes  appeared  in  (1)); 
however,  its  use  has  been  generalized  by  not  specifying  the  properties 
of  the  relation  (in  particular,  the  binary  relation  can  be  that  defined 
by  Mr.  Silver, can  be  an  equivalence  relation  such  as  "identity", 
or  can  be  chosen  to  reflect  relative  security  classification  of  items) . 
The  notion  of  the  safe  permutation  of  processes  has  been  borrowed  from 
Dr.  Habermann’s  work.^l)  It  is  important  to  note  that  all  the  asser- 
tations  about  the  model  to  be  presented  in  this  work  which  use  the 
safe  permutation  can  be  restated  in  terms  of  an  acyclic  digraph — the 
former  representation  (permutation)  is  more  amenable  to  symbolic  mani¬ 
pulation,  while  the  latter  (digraph  and  its  associated  adjacency 
matrix)  may  well  be  more  suitable  for  computer  computations. 

(2) 

In  Mr.  Silver’s  work  the  "safe  situation"  was  equated  with 
the  existence  of  a  loop-free  digraph  representation  of  the  processes. 

In  the  present  work,  the  definition  of  safe  situation  has  been  care¬ 
fully  chosen  (as  in  Dr.  Habermann’s  work)  so  that  it  becomes  quite 
clear  that  the  existence  of  a  safe  permutation  (acyclic  digraph)  is 
a  sufficient  but  not  necessary  condition  for  safety.  This  makes 
clear  the  possibility  that  one  may  discover  a  weaker  necessary  con¬ 
dition  for  safety. 

The  comments  made  by  Mr.  Silver  in  (2) ,  to  wit 

1)  "The  extension  of  the  definitions  and  theorems  to  cover 
this  complication"  (each  process  has  associated  with  it 

a  set  (its  read  set))  "is  straightforward,  but  leads 

to  tiresome  case  analysis." 

2)  "Allowing  new  processes  to  enter  the  scene  does  introduce 
a  new  and  more  subtle  form  of  lockout:  ..."  (permanent 
blocking — see  Holt^), 
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are  reflected  in  the  present  work.  The  case  analysis  for  read-only 
use  is  handled  rigorously  and  the  permanent  blocking  problem  is 
investigated  and  solved  rigorously.  In  addition,  the  present  work 
goes  beyond  the  work  and  suggestions  of  Mr.  Silver^)  by  introducing 
inquiry-use-mode  which  achieves  more  significant  sharing  of  the  data 
base  than  allowed  for  in  the  model  of  (2) . 

My  appreciation  goes  to  Mrs.  Nancy  H.  Anschuetz,  director  of 
MITRE  Department  73  Research  Center,  for  her  assistance  to  me  in 
obtaining  specific  materials  and  for  her  continual  service  to  me  in 
bringing  potentially  relevant  material  to  my  attention. 

I  am  indebted  to  Dr.  David  E.  Bell  (MITRE,  Project  671A)  for 
his  critical  review  of  the  mathematical  portions  of  the  paper  and 
for  the  several  changes  he  suggested  for  clarification  of  the  develop¬ 
ment  and  to  Mr.  Joseph  E.  Sullivan  (MITRE,  D73)  and  Mrs.  Judith  A.  Clapp 
for  their  several  helpful  comments  with  respect  to  the  discussion 
of  COBOL  programs. 
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SECTION  I 


INTRODUCTION 


GENERAL  CONSIDERATIONS 

Just  a  passing  familiarity  with  the  subject  of  multi-user  data 
base  management  easily  convinces  one  that  the  attendant  problems  are 
numerous  and  complex.  The  reader  who  is  unaware  of  the  problems  will 
find  ample,  relevant  exposition  in  (7)  by  Glore  et  al. 

The  problems,  fortunately  I  think,  are  common  to  a  number  of 
technical  subjects  which  at  first  sight  may  seem  only  tangentially 
related.  Resource  sharing,  mutual  exclusion  techniques,  multipro¬ 
cessor  synchronization,  and  in  general,  synthesis  and  analysis  of 
control  mechanisms  for  parallel  systems  -  these  and  other  subjects 
have  relevant  technical  relationships  to  the  subject  of  multi-user 
data  base  sharing. 

I  decided  at  the  outset  of  the  work,  reported  in  the  following 
sections,  that  the  investigation  would  start  at  some  clearly  defined 
point  and  would,  hopefully,  proceed  in  one  direction  at  a  time.  This 
decision  accounts  for  two  characteristics  of  this  report: 

1)  the  material  is  presented  in  the  order  in  which  the  investi¬ 
gation  proceeded  -  as  a  result,  the  reader  will  have  the 
advantage  of  following  a  coherent,  developing  thread  of 
reasoning; 

2)  the  development  leads  to  the  gross  specification  of  a  single 
class  of  systems. 

The  result,  I  think,  is  satisfactory;  for,  the  systems  implied 
by  the  constructed  model  can  perform  real  jobs  in  a  multi-user  envi¬ 
ronment  . 

I  chose  to  approach  the  problems  and  develop  solutions  using 
these  guidelines: 

•that  the  work  should  offer  specific  solutions, 

•that  the  treatment  should  be  as  mathematically  rigorous  as 

required  to  show  that  proffered  solutions  are  indeed  solutions, 

•that  the  work  should  be  related  to  an  easily  realizable  imple¬ 
mentation  of  the  mathematical  model. 
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The  last  guideline  accounts  for  those  sections  which  deal  with  COBOL 
programs  processing  COBOL  files.  While  the  model  is  more  general 
than  the  latter  example,  I  feel  that  the  example  has  a  clear,  direct 
bearing  on  the  processing  needs  of  the  sponsor  of  the  current  applied 
research  effort. 


SUMMARY  OF  THE  REPORT 

In  Section  II  a  formal  model  of  a  system  is  presented.  This 
model  describes  a  set  of  abstract  machines  concurrently  operating  on 
a  common  data  base.  Rules  are  stated  which  are  intended  to  avoid 
conflict  and  deadlock  with  respect  to  the  use  of  a  shared  data  base. 
That  the  rules  suffice  to  provide  this  protection  is  shown  in  the 
form  of  a  number  of  theorems  with  proofs.  In  addition,  an  algorithm 
is  described  which  allows  a  system  to  uniquely  determine  whether  or 
not  a  safe  situation  (free  of  conflict  and  no  possibility  of  deadlock) 
exists.  This  section  represents  the  major  step  toward  the  development 
of  an  adequate  model;  within  the  framework  established  it  becomes 
easy  to  attack  and  solve  specific  problems. 

In  Section  III  the  formal  model  is  reconstructed  in  terms  of 
COBOL  programs  operating  on  a  set  of  COBOL  files.  All  of  the  material 
of  Section  II  is  reviewed,  in  an  intuitive  way  rather  than  by  theorem 
and  proof,  and  the  characteristics  of  the  system  are  discussed.  This 
exercise  also  serves  to  clarify  some  of  the  shortcomings  of  the 
initial  model  and  to  point  to  major  areas  which  require  further 
investigation . 

In  Section  IV  two  of  the  shortcomings  of  the  model  are  removed. 
First,  the  model  is  extended  to  allow  for  read-only  use  of  data.  In 
this  extension,  read-only  use  is  a  property  associated  with  a  process 
rather  than  a  set  of  data  -  the  trivial  case  wherein  a  set  of  data 
is  identified  as  read-only  is  not  treated.  Second,  the  model  is 
extended  to  allow  a  dynamically  changing  set  of  processes  to  operate 
on  the  data  base;  this  extension  introduces  the  problem  of  permanent 
blocking,  for  which  a  solution  is  offered. 

In  Section  V  a  representation  of  the  states  and  behavior  of  the 
model  developed  in  Section  IV  is  presented.  This  representation  has 
some  of  the  characteristics  of  both  Petri  nets  and  graph  programs; 
its  uses  are  as  a  compact  description  and  as  a  specification  for  a 
simulation  of  the  model. 

In  Section  VI  the  formal  model  is  once  again  applied  to  a  set  of 
COBOL  programs  operating  on  a  set  of  COBOL  files.  The  discussion 
deals  with  characteristics  of  the  hypothetical  system  in  general. 
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a  dynamically  changing  set  of  programs,  multiple  read-only  use  of  a 
file,  and  coordination  of  data  sharing  with  the  sharing  of  other 
resources  of  the  system.  Finally,  a  gross  qualitative  analysis  of 
the  system  concludes  that  the  potential  for  concurrent  use  of  files 
must  be  increased  in  order  to  increase  the  usefulness  of  the  hypo¬ 
thetical  system. 

In  Section  VII  the  difficult  problem  of  allowing,  in  some  sense, 
that  many  programs  may  simultaneously  be  reading  and  writing  the 
same  file  is  taken  up  in  terms  of  the  formal  model.  A  method,  called 
inquiry-use  mode,  is  developed,  and  it  is  shown  that  the  processes 
of  the  system  cooperate  harmoniously. 

In  Section  VIII,  which  is  an  extension  of  the  discussion  of 
Section  VI,  the  hypothetical  system  of  COBOL  programs  with  the 
addition  of  inquiry-use  mode  is  examined. 


AUTHOR’S  CONCLUSIONS  AND  RECOMMENDATIONS 

The  principal  objective  of  the  work  -  to  construct  a  canonical 
specification  for  a  reasonable  multi-user,  data  sharing  system  -  has 
been  achieved  in  the  sense  that  the  constructed  model  provides  guid¬ 
ance  for  the  design  of  a  multi-user  data  base  management  system  which 
has  the  properties: 

1)  allows  multiple-user  data  base  sharing,  to  the  extent  that 
many  programs  may  concurrently  be  reading  and  writing  the 
same  file  in  a  restricted-use  mode; 

2)  conflict,  deadlock,  and  permanent  blocking  do  not  occur; 

3)  integrity  of  the  data  base  is  guaranteed  without  qualification 

4)  integrity  of  information  generated  from  the  data  base  can  be 
achieved . 

The  use  of  a  mathematical  discipline  in  the  definition  and  solu¬ 
tion  of  problems  has  proved  helpful  -  to  this  author,  the  method  was 
necessary,  for  at  many  turns  in  the  development  what  seemed  intui¬ 
tively  correct  was  mathematical  nonsense,  with  the  result  that  many 
pitfalls  were  avoided. 

The  section  of  the  paper  which  presents  a  description  of  the 
states  and  behavior  of  the  model  is  both  interesting  and  useful.  The 
description  can  be  used  as  a  specification  for  construction  of  a  simu¬ 
lation;  the  method  of  description,  borrowing  as  it  does  from  Petri  net 
and  graph  program  techniques,  is  interesting  as  a  technique. 
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The  experience  of  producing  this  paper  leads  me  to  two  recommenda¬ 
tions  : 

1)  that  the  development  of  a  model  of  a  multi-user  data  sharing 
system  which  does  not  require  foreknowledge  of  data  require¬ 
ments  should  be  attempted;  it  would  be  informative  to  compare 
such  a  model  to  the  one  presented  herein; 

2)  that  the  available  mathematical  tools  for  representations, 
synthesis,  and  analysis  of  systems  be  brought  to  bear  on  any 
such  undertaking  as  presented  herein — when  the  tools  are  not 
available,  they  should  be  developed. 
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SECTION  II 


AN  ABSTRACT  MODEL  OF  COOPERATING  PROCESSES 


INTRODUCTION 

In  this  section  we  establish  a  basic  model  of  a  system  of  pro¬ 
grams  concurrently  operating  on  a  data  base.  We  give  precise  meanings 
to  the  elements  of  the  model  so  that  they  may  be  dealt  with  mathemati¬ 
cally.  The  elements  of  the  system  are  also  abstracted  from  most  of 
the  considerations  pertinent  to  real  programs  and  data  bases  -  con¬ 
siderations  which,  initially,  are  irrelevant  to  our  purpose. 


STRUCTURE  OF  THE  DATA 


definition 


notation 


definition 


A  data  base,  D^,  is  a  finite,  non-empty  set,  S^,  of 
elements  together  with  a  binary  relation,  R.,  defined 
over  the  elements  of  S.  The  relation  R.  has  an 
unspecified  set  of  properties. 

Small  letters  denote  elements  of  S ;  e.  g. ,  a,  b ,  c, 
...  .  Capital  letters  denote  subsets  of  S;  e.g.,  T, 
U,  V,  ....  If  a  is  related  to  b  by  R,  we  write 
a Rb .  We  denote  the  data  base  by  D  =  (S,  R.)  .  We 
will  also  use  the  ordinary  set  operators  in  their 
usual  way;  e.g.  ,  T  C  U  means  for  every  t  e  T,  t  e  U. 

a  and  b  are  comparab le  if  either  aRb  or  bRa.  We 
denote  this  by  a  ^  b. 


definition 


T  and  U  are  comparable  if  3t  e  T  and  u  e  U  such 
that  t  u.  We  denote  this  by  T  «-»■  U. 


COOPERATING  PROCESSES 

We  consider  the  cooperation  of  a  finite  set  of  processes 
operating  concurrently  on  a  data  base  I)  =  (S,  R)  .  Careful  attention 
must  be  given  to  the  meanings  of  the  terms  "process"  and  "concurrently." 

A  process  is  defined  in  terms  of  an  abstract  machine  in  the 
sense  of  Habermann. In  the  application  of  the  model  to  be  devel¬ 
oped,  the  term  "process"  can  be  used  to  describe  a  broader  class  of 
computer  programs,  as  seems  to  have  been  intended  by  Silver. For 
our  purposes  here,  it  will  prove  convenient  to  use  the  following  defi¬ 
nitions  and  notions. 
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A  sequential  machine  is  a  quintuple  (A,  X,  Y,  f,  g)  where: 

A  is  a  finite  set,  the  elements  of  which  are  called  states; 

X  is  a  finite  set,  the  elements  of  which  are  called  input  signals; 

Y  is  a  finite  set,  the  elements  of  which  are  called  output  signals 

f  is  a  mapping  of  A  x  X  in  A; 

g  is  a  mapping  of  A  x  X  in  Y; 

the  sets  A,  X,  and  Y  are  non-empty. 

Let  (W,  •)  and  (Z ,  •)  be  semigroups  where: 

•  is  a  concatenation  operation; 

W  is  generated  by  elements  of  X; 

Z  is  generated  by  elements  of  Y. 

Extend  f  and  g  to  mappings  of  A  x  W  in  A  and  A  x  W  in  Z,  respec¬ 
tively,  as  follows; 


let  w  =  x^  •  x^ 


•  x  be  an  element  of  W  and  a,  e  A; 
n  j 


the  element  f(a.,  w)  =  a, .  can  be  calculated  from  the  recursive 
J  j+n 

relation  aj+i  =  x±)  for  eac^  *  e  2,  ...,  n}; 

the  element  g(a^,  w)  =  z  where  z  =  y^  •  •  ...  •  y^  can  be 

calculated  from  the  sequence  a.,  a,,-,  ...,  a...  ,  and  the 

j  j+1  j+i-1 

relation  y.  =  g(a.tJ  x_, )  for  each  i  e  {1,  2,  .  ..,  n}. 

°  j+i-1  i 

Consequently,  we  have  the  simple  calculation  rules: 

(1)  f(a..,  wx  •  w2)  =  f (f (a^ ,  v^),  w2) 

(2)  g(a^ ,  wx  •  w2)  =  g(a^ ,  •  g(f(a^,  ,  w2). 

These  rules  are  a  formal  expression  of  our  ordinary  intuitive  notion 
of  the  operation  of  a  finite  state  sequential  machine. 
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Let  a  special  state  a  in  A  be  defined;  call  it  the  initial 
state  and  let  it  be  unique  (i.e.,  for  every  w  e  W  and  a  e  A, 
a  ^  aQ,  g(aQ,  w)  ±  g(a,  w) ) .  Next  we  identify  a  special  subset  of 
W  in  order  to  specialize  the  sequential  machine  with  an  initial 
state  to  our  purposes. 

Let  w  e  W  be  such  that  f(aQ,  w)  =  aQ;  let  w^  •  w2  =  w;  if 
f(aQ,  w^)  ^  a©  for  every  factorization  of  w  then  w  is  called 
the  contents  of  a  task.  We  collect  such  elements  w  e  W  in  the 
special  subset  1  C  W.  Hence,  I  is  a  subset  of  W  such  that  for 
every  w  e  I : 

(i)  f (a  ,  w)  =  a  ; 

o  o 

(ii)  f(a  ,  W-)  ^  a  for  every  factorization  wn  •  w_  =  w. 
o  1  o  12 

In  other  words,  I  contains  all  those  sequences  of  input  signals 
for  which  it  is  true  that,  starting  in  its  initial  state,  the  sequen¬ 
tial  machine  will  again  be  in  its  initial  state  at  the  end  of  the 
sequence  of  input  signals  but  will  not  return  to  its  initial  state 
before  the  end  of  the  sequence  of  input  signals.  We  may  similarly 
define  a  subset  0  C  Z,  where  elements  of  0  are  called  the 
output  of  a  task. 

We  can  now  precisely  define  the  terms  "abstract  machine"  and 
"sequential  process." 

An  abstract  machine  is  a  sequential  machine  with  an  initial 
state  for  which  the  subset  I  is  non-empty. 

A  sequential  process  is  the  series  of  states  generated  by  cal¬ 
culation  of  f(a  ,  w). 

o 

Henceforth,  we  will  be  concerned  only  with  the  special  case  that  the 
abstract  machine  processes  a  task  -  that  is,  w  e  I  defines  the 
input  signals  for  the  machine,  which  starts  at  its  initial  state. 

A  run  of  the  abstract  machine  is  a  sequential  process  defined  for 
some  w  e  I.  When  the  abstract  machine  is  out  of  its  initial  state 
and  in  some  other  of  its  states  or  is  in  its  initial  state  and  has 
been  given  a  w  e  I  to  "process,"  we  say  that  the  abstract  machine 
is  engaged. 

Having  defined  precisely  what  we  are  dealing  with,  we  will  hence¬ 
forth  simply  refer  to  a  process ;  a  process  is  to  be  understood  to  be 
an  abstract  machine  which  processes  tasks.  The  existence  of  a  process 
is  continuous  in  the  sense  that  it  exists  both  when  engaged  and  when 
not  engaged.  The  term  "process"  is  employed  (instead  of  abstract 
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machine)  because  of  its  intuitive  appeal  -  that  is,  the  author  wishes 
to  encourage  the  reader  to  use  his  own  notion  of  "process,"  relying 
on  the  preceding  definitions  only  when  they  are  crucial  to  the  develop¬ 
ment.  So,  for  example,  most  often  it  will  suffice  to  think  of  a 
process  as  a  procedure  in  execution;  or,  one  might  think  of  a  process 
as  an  abstract  entity  whose  states  are  defined  by  execution  of  the 
instructions  of  a  procedure  by  a  processor. 

In  the  operation  of  a  set  of  processes,  time  is  considered  to 
be  a  counter,  the  value  of  which  equals  the  number  of  actions  per¬ 
formed  since  the  start.  An  action  itself  is  considered  timeless. 

In  the  proceedings  of  a  set  of  processes,  two  actions  never 
coincide  in  time,  so  that  a  given  increase  of  time  is  caused  by  only 
one  process.  Thus,  we  suppose  that  time  progresses  in  a  discrete 
series  of  steps,  at  each  of  which  just  one  process  takes  an  action; 
the  discrete  progress  of  time  is  independent  of  the  success  or  failure 
of  the  action. 

Each  process  takes  a  finite  number  of  actions;  thus,  it  is 
guaranteed  that  a  process,  once  engaged  (begun),  will  terminate  its 
processing. 

In  this  section  of  the  paper  we  will  deal  with  a  finite,  fixed 
set  of  processes  _P  =  •••>  En) »  where  Pi  denotes  a  pro¬ 

cess.  We  will  be  concerned  with  one  run  of  the  system  CP,  _D )  :  that 
is , 

1)  the  system  CP,  D)  starts  out  with  all  P  e  _P  in  initial 
states ; 

2)  a  run  of  the  system  extends  from  the  time  of  first  engagement 
of  a  P  e  P_  to  the  time  of  finishing  of  every  P  e  P^  which 
has  been  engaged;  during  a  run  of  the  system,  if  P^ 
finishes,  Pi  may  not  be  engaged  again  until  the  run  of  the 
system  is  terminated  (every  P  e  P_  is  again  in  initial 
state) . 


CONFLICT  AND  DEADLOCK 

Let  _P  =  {P-p  •••>  Pn}  be  a  set  processes  operating  on 

I).  Let  each  Pi  have  associated  with  it  some  subset  Wi  of  S  at 
each  moment  of  its  engagement.  The  subset  is  to  be  understood 

to  contain  all  elements  of  S  which  Pi  is  currently  processing  in 
any  way. 
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definition  conflicts  with  Pj  if  Wi  Wj .  That  is  to 

say  that  both  P^  ana  Pj  are  concurrently  pro¬ 
cessing  elements  of  S,  say  a^  and  a  j  ,  such 
that  a^Raj  or  ajRa^. 

Suppose  we  make  a  rule  which  says  "Pi  may  not  change  its  asso¬ 
ciated  if  the  change  would  cause  it  to  conflict  with  some  other 

process."  The  rule  provides  protection  from  conflict  but  allows  P^ 
to  become  deadlocked  on  I),  as  shown  in  the  following  example: 

Suppose  that,  at  moment  t  =  tQ  in  the  proceedings  of  P_,  P-^ 

and  Pj  are  not  in  conflict  (i.e.,  W-^  ++  Wj  does  not  hold). 

Suppose  further  that  the  next  action  for  Pj  is  to  increase  W-^  to 
W*  (W.  C  W|)  such  that  W^  +-+  Wj  ,  and  that  the  next  action  for  Pj 
is  to  increase  Wj  to  Wj  such  that  Wj  ++  W^.  Neither  P^  nor 
Pj  is  allowed  to  proceed  under  the  proposed  rule.  Generalization 
to  the  n  processes  of  _P  shows  that  P_  can  become  deadlocked  on 
D. 


Clearly,  we  must  do  something  to  avoid  deadlock;  at  the  same 
time,  we  wish  to  allow  P_  to  operate  on  D  in  a  sharing  way:  that 
is,  we  wish  to  avoid  partitioning  of  S  into  disjoint  subsets  asso¬ 
ciated  with  the  processes  of  _P. 

To  this  end,  with  each  P^  we  associate  V-*  C  S  such  that,  at 
any  moment  t  =  t^  during  a  run  of  Pi,  W^  C  Vi  for  all  t  >  t^. 
is  a  subset  of  S  which  establishes  a  bound  on  the  area  of  the  data 
base  in  which  Pi  will  operate;  it  is  a  prediction  of  possible  data 
requirements  of  P^.  At  any  moment,  Vi  is  the  subset  of  S  on 
which  P^  has  a  claim  while  W^  is  the  subset  of  S  which  Pi  is 
using.  Both  W^  and  Vi  may  change  during  the  life  (a  run)  of  P^ 
subject  to  the  restrictions: 

(i)  w±  c  V. 

(ii)  if  V  is  changed  to  V^,  then  v!^  C  V±. 

POTENTIAL  BLOCKING 

We  may  now  define  a  concept  of  potential  blocking  (a  prediction 
of  possible  conflict)  among  processes  in  terms  of  their  associated 
subsets  V. 


9 


definition 


P-£  potentially  blocks  Pj  (notation:  P^  Pj) 
if  i  4  j  and  W^  ++  Vj  .  Pi  Pj  means  that  Pi 
has  wandered  in  13  into  an  area  on  which  Pj  has 
established  a  claim,  although  at  the  moment,  it 
may  be  that  Wi  ++  Wj  does  not  hold. 

We  will  normally  say  simply  that  Pi  blocks  Pj  when  Pi  P j  ; 
we  will  mean  Pi  is  potentially  blocking  P j , 


THE  SAFE  SITUATION 


We  may  now  also  formalize  our  intuitive  notion  of  harmonious 
cooperation  among  the  processes  of  _P. 


definition  The  processes  of  I*  are  in  a  safe  situation  at 

moment  t  if  for  every  process  P^  the  moment 
t^  >  t  can  be  reached  at  which  the  relation: 


NOTE: 


P  P,  for  every  j  c  N  =  { T,  2,  . ,  .  ,  n}  holds. 

J 

P.  -/->  P,  means  P,  is  not  potentially  blocked  by  P 
j  k  k. 


(1) 


RULES  OF  COOPERATION 


We  now  state  a  set  of  rules  which,  we  will  show,  guarantee 
that  the  processes  of  P_  may  harmoniously  operate  on  D;  that  is, 
the  data  base  may  be  shared  while  it  is  guaranteed  that  deadlock  will 
not  occur. 

Rule  1:  Each  process  P^  begins  operation  with  a  bound,  Vj  ,  on 
its  W-£.  (Initially,  W^  ■  <{>;  i.e.,  the  empty  set.; 

Rule  2:  A  process  P-j_  may  not  change  its  associated  W^  if  the 

change  would  cause  it  to  conflict  with  some  other  process. 

Rule  3:  At  each  moment  of  time,  one  of  the  processes,  say  P,  takes 
an  action,  changing  its  state  in  one  of  four  ways: 


(1) 

P 

finishes 

,  reducing  W  and  V  to  the  empty  set, 

(2) 

P 

changes 

W,  subject  to  W  C  V, 

(3) 

P 

changes 

V  to  Vf  ,  subject  to  Vf  C  V,  or 

(A) 

V 

and  W 

remain  unchanged. 

10 


HARMONIOUS  COOPERATION  IN  (P,  D) 


Theorem  1 


Proof : 


Theorem  2 


Proof : 


Theorem  3 


Let  P  change  its  state  according  to  R3.  If  in 
the  new  state  P^-*  P,  then  this  was  true  in  the 
old  state  as  well. 

P^  P  means  Vf  (where  Vf  denotes  the 

bound  for  P  after  its  state  change).  Vf 

implies  3w  e  and  vf  e  V’  such  that  w  vf . 

But  vf  e  V  since  V1  C  V  so  that  ++  V  and 

Pi  P  in  the  old  state  as  well. 


Assume  that  the  next  action  of  each  P^  is  to 
increase  to  (i.e.,  make  -  V^-)  .  If 

the  set  of  processes  is  in  a  safe  situation  at 
this  moment,  then  there  exists  some  Pj  which  is 
not  potentially  blocked  by  any  other  process. 

Assume  the  theorem  is  false.  Then  for  every 
j  3i(j)  such  that  ^i(j)  at  this  moment. 

pi(j) +  pj  impiies  uKj> "  vj 

so  that  if  Pj  makes  Wj  =  Vj  we  have  ++  Wj  , 

but  this  is  not  allowed  by  Rule  2.  Therefore,  Pj 
may  not  take  its  next  action.  But  this  is  true 
for  all  the  processes.  Since  no  process  may  take 
its  next  action,  there  is  no  time  tj  at  which 
Pj  is  not  potentially  blocked  (i.e.,  the  situation 
is  not  safe) . 


If  the  set  of  processes  P  can  be  arranged  in  a 
sequence  P]_,  P2,  .  Pn  such  that  for  each  P^, 
k  e  {1,  2,  . . . ,  n-1 }, 

P  -/->  P,  for  j  e  {k+1,  k+2,  ...,  n),  (2) 

J  k 

then  the  situation  is  safe. 
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Proof : 

Suppose  that  a  permutation  of  the  processes  has  the 
property  (2).  Then  relation  (1)  holds  for  P^ 

(i.e.,  Pj  — /->  P*l  for  every  j  e  N)  .  By  Theorem  1, 
P*L  may  complete  all  of  its  actions  since  it  cannot 
become  blocked  by  any  action  it  takes  and  hence 
cannot  conflict  with  any  other  process.  Thus,  there 
exists  some  moment  t1  at  which  P^  can  finish 
its  processing.  At  moment  t',  relation  (1)  holds 
for  s0  that  P2  may  be  allowed  to  proceed  to 

completion.  Continuing  in  this  way,  we  find  that 
for  each  P^  there  is  some  moment  t^  at  which 

P_.  — /->  P^.  for  every  j  e  N. 

definition 

A  safe  permutation  is  an  arrangement  of  the  processes 
which  satisfies  (2). 

Corollary  1: 

If  a  safe  permutation  of  the  processes  exists  at 
moment  t,  then  it  is  guaranteed  that  some  process 

P  can  take  its  next  action  in  accordance  with  the 
rules,  and  the  situation  will  be  safe  at  moment  t+1. 

Proof : 

Follows  from  Theorem  3;  in  fact,  is  merely  a  restate¬ 
ment  of  Theorem  3  to  make  explicit  the  guarantee 
that  some  process  may  take  its  next  action  without 
causing  the  situation  to  become  unsafe. 

Theorem  4 

Assume  that  the  next  action  of  each  P^  is  to 
increase  to  V^.  Then  the  set  of  processes  is 

safe  if  and  only  if  a  safe  permutation  of  the  pro¬ 
cesses  exists. 

Proof : 

If  a  safe  permutation  exists,  then  the  situation  is 
safe  by  Theorem  3.  Conversely,  assume  that  the 
situation  is  safe  at  moment  t  =  tQ.  By  Theorem  2, 
there  is  some  process  which  is  not  potentially 
blocked  by  any  other  process.  Call  this  process 

P]_.  (If  more  than  one  exists,  select  any  one.) 

Let  K;l  =  {Pj  :  j  ^  1} .  Let  P]^  proceed  to  com¬ 
pletion,  say  at  time  t1.  By  Theorem  2  at  time 
t  =  tT,  there  exists  some  process  in  which 

is  not  potentially  blocked  by  any  other  process  in 

K-,  .  Select  one  such  process  and  name  it  P2.  At 
time  t  =  tQ,  (2)  clearly  holds  for  P2-  Continue 
by  induction,  eventually  constructing  a  permutation 
Pi,  P2,  .  ..,  Pn  which  satisfies  (2)  at  time  t  =  tG. 
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definition 

A  loop  in  P  =  (P^,  Po  *  . . . ,  Pn)  is  a  set  of  dis- 
tinct  processes  ?]_>  P^>  •••»  ?k  (k  2.  2)  such 
that  Pj_  ->  P£  -►  ...  P£  ->  P^.  If  no  loops  exist 

in  P,  then  P  is  said  to  be  loop-free. 

Lemma  1: 

If  the  set  of  processes  P_  is  loop-free,  then 
there  exists  some  process  which  is  not  blocked  by 
any  other  process. 

Proof : 

Assume  the  lemma  is  false.  Then,  for  every  j, 

3i(j)  such  that  pi(-j)  **  P j  •  Pick  any  process, 
say  P^.  Let  =  jP  -  { P -j_ } .  Then,  there  exists 

some  process,  say  P£,  in  Ki  such  that  P£  P^. 

Construct  K2  =  Ki  -  {P^}  and  pick  P^.  Continue 
in  this  way;  at  each  step  of  the  process  if  we  pick 
the  next  process  from  (by  we  mean  comple¬ 

ment  of  the  set  K)  that  introduces  a  loop.  Even¬ 
tually  we  may  come  to  ^-1  which  contains  only 
one  process;  this  process,  by  assumption,  is  blocked 
J^y  some  other  process,  but  the  latter  must  be  in 

K  n  so  that  a  loop  exists. 
n-1  r 

Theorem  5 

If  the  set  of  processes  P  is  loop-free,  then  the 
situation  is  safe. 

Proof : 

Assume  the  set  is  loop-free.  Then  there  exists 
some  process,  say  Pi,  which  is  not  blocked  by 
any  other  process.  Let  =  {P^  :  i  ^  1}.  No 

loop  exists  in  K-^;  hence,  there  exists  some  pro¬ 
cess,  say  P2,  which  is  not  blocked  by  any  other 
process  in  K^.  Continuing  inductively,  we  can 
construct  a  safe  permutation.  Hence,  by  Theorem  3, 
the  situation  is  safe. 

Theorem  6 

Assume  that  the  next  action  of  each  P^.  is  to 
increase  to  V^.  The  set  is  loop-free  if  and 

only  if  it  is  safe. 

Proof : 

Assume  the  set  is  loop-free.  Then  it  is  safe  by 
Theorem  5.  Conversely,  assume  it  is  safe.  By 
Theorem  4,  a  safe  permutation,  say  tt,  exists. 

Now  assume  that  a  loop  exists,  say 

p »  P »  p»  ^  pf 

*1*2  ••  •  k  *r 
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By  relation  (2)  ,  must  precede  P’  in  tt  for 

j  e  {i+1,  k}  and  P£  must  precede  Pj_  since 

P’  P ’ .  So  we  have  that  both 

k  1 

P^  precedes  P^  in  tt  and 

P^  precedes  P|  in  tt 

which  is  impossible.  Therefore,  no  loops  exist. 

Corollary  2: 

Assume  that  the  next  action  of  each  P^  is  to 
increase  to  Vfc.  Then  a  safe  permutation  exists 

if  and  only  if  the  set  P^  is  loop-free. 

Proof : 

Follows  from  Theorems  4  and  6. 

Theorem  7 

A  safe  permutation  of  P_  exists  if  and  only  if 

P^  is  loop-free. 

Proof : 

Assume  that  a  safe  permutation  exists,  say  tt. 

Now  assume  that  a  loop  exists,  say 

pi  *  p2  *  •  ••  pk  ^  pr 

By  relation  (2)  ,  Pj^  must  precede  Pj  in  tt  for 
j  e  {i+1,  k}.  Also,  P£  must  precede  P|  in 

tt  since  P£  ■+  P^.  So  we  have  that  both 

P^  precedes  P£  in  tt  and 

P^  precedes  P|  in  tt 

which  is  impossible.  Therefore,  no  loops  exist. 
Conversely,  assume  the  set  is  loop-free.  Then 
there  exists  some  process,  say  P^,  which  is  not 
blocked  by  any  other  process.  Let  =  (P^  :  i  ^  1} 

No  loop  exists  in  K^;  hence,  there  exists  some 
process,  say  P2,  in  which  is  not  blocked  by 

any  other  process  in  K^.  Continuing  inductively, 
we  can  construct  a  safe  permutation. 

Theorem  8 

The  assertion  Mthe  situation  is  safe  if  and  only  if 
a  safe  permutation  of  the  processes  exists”  is  false. 
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Proof : 


The  proof  is  by  counterexample.  Let  P_  =  {P^,  P2}. 
Suppose  that  at  moment  t  =  tD,  the  situation  is 
safe  while  P-^  P2  and  P2  P^*  To  show  that 
this  is  possible,  we  give  a  representation  of 
W^,  W2,  Vlf  and  V2  at  time  tD  and  a  list  of 
actions  for  P^  and  P2  which  show  that  P^ 
reaches  some  moment  t^  >.  to  at  which  it  is  not 
potentially  blocked  by  any  other  process.  Let 
W^,  W2 ,  V^,  and  be  as  follows: 


The  next 

actions  for  _P  are: 

t  + 
0 

1: 

pi 

reduces  to  the  empty  set 

t  + 
0 

2: 

P2 

increases  W0  to 

t  + 
0 

3: 

P2 

reduces  to  the  empty  set 

t  + 
0 

4: 

P1 

increases  to 

t  + 
0 

5: 

P2 

finishes 

t  + 
0 

6: 

P1 

finishes 
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At  time  tQ  +  1,  ?2  is  not  blocked  by  any  other 
process.  At  time  tQ  +  3,  is  not  blocked  by 

any  other  process.  Thus,  the  processes  are  able  to 
complete  their  actions  without  conflict  or  deadlock. 
Yet,  no  safe  permutation  exists  at  time  tQ.  There 
are  two  permutations,  neither  of  which  satisfies 
the  relation  (2). 

Corollary  3: 

The  assertion  "the  situation  is  safe  if  and  only  if 
the  set  of  processes  is  loop-free'1  is  false. 

Algorithm  a 

Algorithm  a  is  given,  whereby  a  safe  permutation 
may  be  chosen.  Assume  the  situation  is  safe  and 
that  a  safe  permutation  exists  at  moment  t  =  tQ. 
Further,  suppose  that  process  wishes  to  change 

its  state.  Then,  pretend  that  P^  has  so  changed 
its  state  so  that  we  are  at  moment  tQ  +  1.  To 
find  a  safe  permutation,  proceed  as  follows:  Look 
for  any  process  for  which  relation  (2)  holds;  i.e., 
suppose  we  pick  P^,  then 

Pj  -b  P|  for  j  e  {2,  ...,  n}. 

Among  the  remaining  processes,  pick  any  process 
for  which  relation  (2)  holds  and  designate  it  P^. 
Continue  in  this  way.  If,  after  k  steps  of  this 
procedure,  we  are  unable  to  find  a  next  qualifying 
process,  then  we  may  stop  looking  for  a  safe  permu¬ 
tation  since  none  exists.  We  prove  the  last  asser¬ 
tion  in  the  form  of: 

Theorem  9 

The  algorithm,  a,  decides  uniquely  whether  or  not  a 
safe  permutation  exists. 

Proof : 

Suppose  that  after  k  steps  through  a  there  is 
no  next  qualifying  process.  That  is,  we  have  con¬ 
structed  partial  permutation  TrQ  =  P^,  P£ ,  ...,  P£. 
Then,  there  are  at  least  two  processes  in  ]P  which 
do  not  appear  in  TrQ>  since  otherwise  we  should 
have  succeeded  in  finding  a  safe  permutation.  For 
this  set  of  processes,  which  we  designate  as  P_’ 1  , 
there  is  no  process  which  is  not  potentially  blocked 
by  any  other  in  the  set,  since  if  there  were,  we 
should  have  succeeded  in  getting  to  the  k  +  1  step 
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of  a.  Moreover,  by  Theorem  7,  a  loop  exists  in 
]? 1  ;  hence,  a  loop  exists  in  ]?.  Therefore,  no 
arrangement  of  the  processes  can  satisfy  relation 
(2);  i.e.,  there  is  no  safe  permutation. 


Theorem  10  Let  a  safe  permutation  exist  at  moment  tQ.  If,  in 

the  application  of  algorithm  a  to  determine 
whether  or  not  a  safe  permutation  exists  at  tQ  +  1 
if  we  allow  its  next  action,  it  turns  out  that 

P^  is  chosen,  so  that  we  have  a  partial  permutation 
Pi,  p2*  •••*  Pk  for  which  relation  (2)  holds  (i.e., 
for  each  j  e  (1,  2,  • . • t  k}  Pj  for 

i  e  { j ,  j41,  .  ..,  n},  then  a  safe  permutation  exists 
at  tQ  +  1  if  we  allow  P^  its  next  action. 

Proof :  Assume  we  have  arrived  at  partial  permutation 

*o  -  pl>  p2>  • • • >  pk- 

At  time  tQ  there  were  no  loops  since  a  safe  per¬ 
mutation  existed.  Assume  that  there  is  no  safe 
permutation  at  tQ  4  1.  Then,  by  Theorem  7,  a  loop 
exists  in  the  set  _Pf  =  P_  -  (pl>  p2>  •  ••>  P^}* 

Since  P^  alone  has  been  assumed  to  cause  time  to 
move  from  tQ  to  tG  +1,  its  action  must  have 
generated  the  loop  in  _Pf  .  But  this  is  impossible 
since  tt0  guarantees  that  P^  is  not  blocked  by 
any  process  in  ]?f .  Thus,  our  assumption  that  no 
safe  permutation  exists  at  tQ  4  1  leads  to  con¬ 
tradiction. 


Let  (J?,  I))  denote  a  system,  where  _P  is  a  set  of  processes 

(pl»  p2 .  Pn)  and  D  is  a  data  base  (S,  R)  ,  on  which  we 

impose  the  conditions: 

1)  the  processes  obey  the  rules  1  through  3; 

2)  the  system,  during  a  run,  will  allow  an  action  by  P  e  J? 
only  if  the  resulting  situation  is  safe  as  determined  by 
algorithm  a; 

3)  in  case  a  process  may  not  take  its  next  action,  it  is 
stopped  in  its  processing;  it  is  allowed  to  proceed  at 

some  subsequent  moment  only  if  2)  is  satisfied;  the  decision 
to  try  to  restart  a  suspended  process  may  be  determined  by 
any  method — it  must  only  be  guaranteed  that  the  effort  to 
restart  will  be  made  within  a  finite  amount  of  time. 
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Then  (_P,  D)  is  a  system  of  processes  which  harmoniously  cooperate 
in  the  processing  of  a  common  set  of  data.  This  is  stated  in  the 
form  of: 


Theorem  11 

The  processes  of  the  system  (£,  D)  cooperate 
harmoniously. 

Proof : 

It  is  clear  from  Rule  2,  Theorem  3,  Corollary  1, 
and  conditions  1)  and  2)  that  conflict  and  deadlock 
do  not  occur  during  a  run  of  the  system  (P,  D) 
and  that  at  each  moment  during  a  run  of  the  system 
some  process  may  take  its  next  action.  Since  the 
set  I?  is  finite  and  processes  which  have  finished 
do  not  become  engaged  again  and  since  condition  3) 
guarantees  that  a  suspended  process  will  get  another 
chance  to  continue  processing,  every  process  may 
get  another  chance  to  continue  processing,  every 
process  may  get  access  to  all  elements  of  S  which 
it  had  claimed  and  will  finish  in  a  finite  amount 
of  time.  Thus,  (P^,  D)  is  a  system  of  harmoniously 
cooperating  processes  operating  on  a  common  set  of 
data. 
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SECTION  III 


THE  MODEL  APPLIED  TO  A  SET  OF  COBOL  PROGRAMS 


INTRODUCTION 

The  abstract  model  of  Section  II  can  be  realized  in  a  variety  of 
ways.  We  present  here  a  specific  description  of  a  realization  and 
restate  the  material  of  Section  II  in  prose  form,  wherein  the  reader’s 
intuitive  notions  replace  the  formalisms  and  proofs  of  the  previous 
section. 


STRUCTURE  OF  THE  DATA 

The  abstract  model  of  a  data  base  I)  =  (S,  R)  is  interpreted 
as  follows: 

Let  the  elements  of  S  =  {a,  b,  c,  . ..,  z}  represent 
files  in  the  COBOL  sense.  Let  the  relation  R  represent 
ordinary  identity.  Thus,  a  R  b  means  a  =  b;  i.e.,  a  and 
b  are  the  same  file.  Then  we  have  the  simple  result  that 
subsets  T  and  U  are  comparable  if,  in  the  ordinary  set- 
theoretic  sense,  T  O  U  ^  <J> ;  this  means  simply  that  T  and 
U  both  include  at  least  one  file  in  common.  For  example,  if 
T  =  {a,  b,  c}  and  U  =  {c,  d,  e}  then  T  •*-*  u  since  the 
file  c  is  a  member  of  both  T  and  U. 


COOPERATING  PROGRAMS 

We  replace  the  term  ,,process,,  with  the  term  ’’COBOL  object  pro¬ 
gram.”  Our  consideration  now  turns  to  the  cooperation  of  a  finite 
set  of  COBOL  programs  operating  concurrently  on  the  data  base 
D  =  (S,  =)  described  above.  The  same  constraints  on  the  COBOL  pro¬ 
grams  apply  as  were  applied  to  the  abstract  processes:  in  particular, 
each  COBOL  program  takes  a  finite  number  of  actions  so  that  it  is 
guaranteed  that  a  program,  once  begun,  will  terminate  its  processing. 
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CONFLICT  AND  DEADLOCK 


Let  C  =  (C]_,  C2>  C3,  .  ..,  Cxi)  be  a  finite  set  of  COBOL  programs 
operating  on  ID.  Let  each  C^  have  associated  with  it  some  subset 
W^  of  S  at  each  moment  during  its  run.  W^  contains  all  the  files 
in  S  which  C-^  is  currently  processing  in  any  way:  C-^  may  be 
reading,  creating,  updating  the  files  in  W-^. 

We  may  now  describe  conflict  between  two  COBOL  programs  of  C^ 
quite  easily;  C-^  and  Cj  conflict  if  both  of  them  are  currently  pro¬ 
cessing  at  least  one  file  in  common.  For  example,  while  C-^  is  reading 
file  e,  Cj  may  be  updating  it  -  this  is  conflict.  Conflict  now 
has  a  real  meaning:  cleatly,  the  file  read  by  C-^  may  be  an  unpre¬ 
dictable  mixture  of  the  old  file  e  (before  Cj  did  its  updating) 
and  the  new  file  e  (after  Cj  did  its  updating),  so  that  the 
information  delivered  to  C^  is  inconsistent.  In  practice  ,  conflict 
may  be  even  more  severe  than  this.  If  both  programs  are  updating 
the  same  random  file  and  affecting  the  same  index  to  that  file,  con¬ 
tamination  may  even  affect  the  system  which  runs  the  programs  so  that 
the  data  base  gets  beyond  repair. 

Suppose  we  make  the  rule: 

"C.£  may  not  change  its  associated  W^  if  the  change  would 
cause  it  to  conflict  with  some  other  COBOL  program.” 

This  provides  protection  from  conflict  but  allows  deadlock  to  occur, 
as  we  show  in  the  following  example: 

Suppose  that  C]_  is  processing  files  a,  b,  and  c 
and  that  C2  is  processing  files  d,  e,  and  f.  Clearly 
Ci  and  C2  are  not  in  conflict.  Now  suppose  that  program 
Ci ,  in  order  to  complete  its  run,  must  have  access  to  file 
d  while  not  relinquishing  its  hold  on  a,  b,  and  c  and 
that  program  C2  similarly  must  have  access  to  file  a. 

When  program  C]_  asks  for  access  to  d,  the  request  must 
be  denied,  for  to  grant  it  would  cause  C-^  to  conflict 
with  C2,  so  that  C^  must  wait  for  file  d  to  be  released. 
Similarly,  C2*s  request  for  file  a  must  be  denied  so 
that  it  waits  also.  We  have  now  a  deadlock,  C^  waiting 
for  C2  and  vice  versa  so  that  neither  will  ever  finish. 

We  certainly  must  avoid  such  a  situation;  at  the  same  time, 
however,  we  do  not  want  to  impose  rules  on  the  programs  which  are  so 
restrictive  that  we  effectively  would  eliminate  shared  use  of  the 
data  base. 
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To  this  end,  we  associate  with  each  COBOL  program  another  subset 
of  the  files  in  the  data  base.  This  subset,  which  we  have  denoted  by 
V,  tells  the  system  in  which  the  programs  run  what  files  may  at  some 
time  be  simultaneously  needed  by  each  program  during  its  run.  For 
example,  if  for  C]_,  we  have  =  (a,  b,  d,  f,  h),  this  means  that 
during  a  run  of  the  COBOL  program  C^  it  may  simultaneously  have 
open  all  the  files  a,  b,  d,  f,  and  h.  On  the  other  hand,  it  may  not 
have  all  the  declared  files  open  simultaneously;  that  is,  it  may  do 
something  like  the  following: 

PROCEDURE  DIVISION. 


OPEN  a. 


OPEN  b. 


OPEN  d. 


CLOSE  a. 


OPEN  f. 


CLOSE  b. 


OPEN  h. 


CLOSE  d. 
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CLOSE  f. 


CLOSE  h. 


<end> . 

so  that  at  no  time  does  it  have  all  the  files  in  V  open  at  the  same 
time.  However,  such  information  is  not  supplied.  We  assume  the 
worst  case  -  that  all  the  files  may  be  open  simultaneously. 

How  does  the  subset  V  become  established?  In  COBOL  the  subset 
V  is  implicitly  identified  in  the  INPUT-OUTPUT  SECTION.  section, 
FILE- CONTROL.  paragraph,  wherein  each  file  to  be  used  by  the  program 
is  named  in  a  SELECT  statement.  The  compiler  need  only  make  an 
explicit  V-list  declaration  a  part  of  the  object  program,  so  that 
Vi  for  Ci  may  be  established  by  the  system  before  Ci  takes  its 
first  action. 

The  subset  Wi  associated  with  a  Ci  is  dynamically  maintained 
by  the  system  in  which  Ci  runs.  Wi  at  any  moment  during  a  run  of 
Ci  is  a  list  of  all  the  files  which  Ci  has  open  (i.e. ,  files  for 
which  Ci  has  issued  an  OPEN  but  not  a  CLOSE) . 

Note  the  following  important  restraint  imposed  by  the  model  of 
Section  I:  The  COBOL  programs  are  not  allowed  to  use  the  COBOL  LINK 
statement  since  this  might,  in  effect,  increase  the  associated  V. 
This  is  a  particular  form  of  the  general  constraint  that  all  the 
programs  in  C^  are  independent  of  each  other  except  for  the  sharing 
of  D. 

Finally,  both  Wi  and  may  change  during  a  run  of  C^  with 

the  restrictions: 

(i)  WiCVi; 

(ii)  if  is  changed  to  V^,  then  C  V±. 


A  generic  usage  to  be  understood  to  mean  a  statement  set  appropriate 
to  the  specific  implementation  of  COBOL;  e.g. ,  ENTER  LINKAGE 

CALL  entry name 
ENTER  COBOL 
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(i)  means  that  may  not  OPEN  a  file  which  has  not  been  declared 

to  be  a  member  of  V^;  (ii)  means  that  may  reduce  the  set  of 

files  on  which  it  has  established  a  claim  but  may  not  add  files  to 
its  claim  list  (i.e.,  the  list  of  files  given  by  its  associated  V) 
during  a  run. 

POTENTIAL  BLOCKING 

With  the  establishment  of  a  W  and  a  V  for  each  program,  we 
have  made  it  possible  for  the  system  to  detect  impending  danger  of 
conflict  and  thereby  to  avoid  deadlock. 

Consider  an  example.  Suppose  for  COBOL  program  C-^  we  have 
=  (a,  b,  c)  and  for  COBOL  program  C2  we  have  V2  =  (c,  d,  e} . 
Let  W 1  =  { c)  and  W2  =  { d)  .  We  can  see  the  imminent  danger  here, 
for  C2*s  next  action  may  be  to  request  the  use  of  c.  Notice  that 
Wi  n  v2  ^  :  that  is,  c  is  a  member  of  both  W^  and  V2 .  In 

such  a  case,  we  say  that  C^  is  potentially  blocking  C2 ,  for 
should  C2  request  c,  the  request  would  be  denied  and  C2  would 
in  fact  be  blocked  in  its  attempt  to  continue.  This,  in  itself,  is 
not  disastrous;  but  it  is  important  to  know  that  C^  is  potentially 
blocking  C2  for  if  C2  were  also  potentially  blocking  C^,  then 
the  danger  of  deadlock  would  exist.  Consider  the  example: 


=  {  a ,  b  ,  c) 
W  =  { b) 


V2  =  {b,  c,  d} 


W. 


2 


Ci **  C2  (our  notation  which  says  C^  is  potentially  blocking  C2) 
because  b  is  in  both  W^  and  V2.  C2  +  Cl  because  c  is  in  both 
W2  and  Vi.  If  the  next  actions  of  C^  and  C2  are  to  request  use 
of  c  and  b,  respectively,  then  C^  and  C2  are  in  a  deadly 
embrace  (deadlocked) .  Notice  also  that  at  the  moment  we  have  a  loop 
of  potential  blocking: 


Also,  C^  and  are  not  in  conflict;  W^  fl  W^  =  (() 
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THE  SAFE  SITUATION 


We  now  explain  the  safe  situation  in  terms  of  and  I).  The 

programs  of  are  in  a  safe  situation  at  moment  t  if  every  program 

can  have  simultaneous  access  to  all  of  the  files  in  its  V-list  within 
a  finite  amount  of  time.  This  can  be  said  more  precisely  in  terms  of 
our  notion  of  potential  blocking:  The  programs  are  in  a  safe  situa¬ 
tion  at  moment  t  if  for  each  program  the  moment  tk  .>  t  can 

be  reached  at  which  it  is  true  that  Ck  is  not  potentially  blocked 
by  any  other  program;  at  the  moment  tk,  no  process  is  using  any  of 
the  files  in  Ck's  V-list  so  that  Ck  can  get  access  to  all  the 
files  it  had  claimed  and  can  finish  its  processing. 

RULES  OF  COOPERATION 

The  rules  of  cooperation  given  in  Section  I  are  restated  in 
terms  of  C  and  D. 

Rule  1:  Each  COBOL  program  C ^  begins  operation  with  an  established 
list,  Vi,  of  files  which  it  may  require  and  an  associated 
list,  Wi,  of  files  which  it  has  open;  initially,  W^  is 
emp  ty . 

Rule  2:  A  COBOL  program  may  not  open  a  file  if  the  file  is  already 
being  used  by  some  other  COBOL  program. 

Rule  3:  With  respect  to  the  files  which  a  program  C  is  using  or  may 
use,  the  program  may  change  its  state  in  one  of  three  ways: 

(1)  C  finishes,  making  V  and  W  empty; 

(2)  C  changes  W  by  opening  or  closing  a  file,  but  only 
a  file  which  was  declared  in  its  V-list; 

(3)  C  changes  V  by  deleting  entries;  this  means  it  will 
never  in  the  course  of  the  rest  of  its  run  require  the 
files  whose  names  have  been  deleted  from  its  V-list. ^ 


A  mechanism  for  reducing  V-list  does  not  currently  exist  in  COBOL; 
a  new  statement  set  would  be  required  to  implement  this  capability. 
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With  respect  to  the  file  actions  indicated,  we  must  retain  the 
condition  that  only  one  program  at  a  time  takes  an  action;  however, 
as  for  other  activity  we  do  not  care  if  many  programs  take  actions 
simultaneously  as  might  be  the  case  in  a  multiprocessor  environment. 
With  respect  to  Rule  2:  We  do  not  expect  the  COBOL  program  to  decide 
whether  or  not  it  can  safely  open  a  file;  rather,  when  the  program1 s 
OPEN  statement  is  encountered,  the  system  must  inspect  the  situation 
and  decide  whether  or  not  to  allow  the  program  to  open  the  file.  If 
it  is  decided  that  the  program  cannot  open  the  file,  the  system  must 
suspend  the  program  and  restart  it  when  the  situation  clears  up.  One 
way  to  trigger  the  restart  is  to  have  the  system  inspect  a  queue  of 
suspended  programs  to  find  a  candidate  for  restart  every  time  a  file 
is  closed. 


HARMONIOUS  COOPERATION  IN  (C,  D) 

As  was  suggested  in  the  previous  discussion,  the  system  in  which 
CC,  JD)  is  embedded  becomes  involved  with  the  management  of  the  pro¬ 
grams  in  C.  In  particular,  the  system  must  take  cognizance  of  every 
action  having  to  do  with  the  declaration,  opening,  and  closing  of 
files;  in  addition,  the  system  must  maintain  a  queue  of  suspended 
programs — i.e.,  those  programs  which  have  attempted  to  open  a  file 
but  which  have  been  denied  access  temporarily. 

The  theorems  of  the  previous  section  give  us  a  method  whereby 
the  system  may  determine  whether  or  not  it  is  safe  to  allow  a  particu¬ 
lar  OPEN  to  be  executed.  The  method  was  designated  algorithm  a,  and 
it  was  shown  in  Theorem  9  that  the  algorithm  determines  uniquely 
whether  or  not  a  safe  sequence  of  the  programs  exists.  A  safe  sequence, 
say 


Cr  ^2  ’  *  *  *  * 

of  programs  in  C^  means  that 


1) 

for  Ci 

it 

is  true  that  no  other  program  currently  has 

open 

any  file 

in 

C1?s  V-list ; 

2) 

for  C2 

it 

is  true  that  none  of  the  programs 

C3>  C4 , 

•  • • » 

has  open 

any 

file  in  its  V-list; 

3) 

in  general, 

for  Ci  it  is  true  that  no  other 

program 

Cj 

where  i 

<  j 

<_  n  has  open  any  file  in  Ci's 

V-list. 
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Algorithm  a  shows  how  the  system  may  construct  a  safe  sequence: 
the  system  picks  any  program  which  can  qualify  as  a  Ci  in  the  example 
above,  then  looks  for  any  C2,  and  so  forth.  In  addition,  Theorem 
10  shows  that  a  computational  shortcut  exists,  so  that  the  system 
need  only  construct  a  sequence  up  to  the  point  where  it  contains  the 
program  which  is  requesting  the  opening  of  a  file. 

Finally,  Theorem  7,  which  shows  that  a  safe  sequence  exists  if 
and  only  if  C  is  loop-free,  means  that  an  alternative  algorithm 
for  deciding  safety  in  terms  of  a  directed  graph  exists. 


DISCUSSION  OF  THE  SYSTEM  (C,  D) 

The  system  (C^,  I))  has  the  characteristic  that  the  programs 
may  operate  concurrently  on  a  data  base  while  it  is  guaranteed  that 
conflict  and  deadlock  will  not  occur;  this  means  that  no  program  will 
ever  get  stuck  in  its  processing  and  that  the  data  base  will  never 
suffer  loss  of  integrity. 

However,  we  should  expect  that  for  most  multi-user  systems,  the 
system  (C,  D)  will  be  unacceptable  on  a  number  of  counts.  The 
system  (£,  _D) 

1)  makes  no  provision  for  a  dynamically  changing  set  _C:  that 
is,  it  does  not  allow  that  programs  (processes)  may  enter 
and  leave  the  system  from  time  to  time; 

2)  makes  no  provision  for  the  special  case  wherein  a  set  of 
programs  could  safely  concurrently  read  the  same  file; 

3)  does  not  coordinate  the  data  sharing  with  resource  sharing 
(another  source  of  conflict  and  deadlock) ; 

4)  uses  the  file  as  a  unit  of  lock-out:  the  file  might  prove 
too  gross  a  unit  for  many  applications; 

5)  makes  no  provision  for  the  user  to  make  strategy  decisions 
which  could  optimize  system  use  and  performance  for  a  given 
application. 

Undoubtedly,  the  reader  can  add  to  this  brief  list.  Nevertheless, 
we  have  so  far  achieved  the  result  that  we  can  define  a  system  which 
behaves  in  a  pre-determined  way  to  avoid  the  problems  of  conflict  and 
deadlock  in  concurrent  use  of  a  data  base.  We  have  now  to  refine, 
extend,  or  otherwise  change  our  model  as  we  attempt  to  eliminate  those 
characteristics  of  the  system  which  are  undesirable. 
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SECTION  IV 


EXTENSION  OF  THE  MODEL 


INTRODUCTION 

In  this  section  the  model  of  Section  I  is  extended  to  distinguish 
read-only  use  from  read-write  use  of  elements  of  S  and  to  allow  a 
dynamically  changing  set  _P. 

EXTENSION  TO  ALLOW  INCREASED  SHARING  FOR  READ-ONLY  USE 
Conflict  and  Deadlock 


Let  P_  =  {P^,  P2j  . ..,  Pn^  be  a  set  °f  processes  operating  on 
I).  Let  each  Pi  have  associated  with  it  a  subset  Ri  of  S  at 
each  moment  of  its  engagement.  The  subset  Ri  is  to  be  understood 
to  contain  all  elements  of  S  which  F±  is  currently  using  but  not 
changing:  that  is,  r  e  R±  guarantees  that  does  not  change  r 

in  any  way — thus,  R^  represents  a  read-only  set  of  elements  with 
respect  to  Pi  (we  allow  that  some  Pfc  may  wish  to  claim  an  element 
of  R±  for  read-write  use) .  With  each  Pi  we  also  associate  a  sub¬ 
set  Qi  which  establishes  a  bound  for  Ri,  just  as  Vi  establishes 
a  bound  for  P^s  associated  Wi. 

We  re-interpret  the  subset  Wi  to  include  only  those  elements 
of  S  which  Pi  may  change  during  its  engagement. 

We  have : 


(i) 

W±c  vi 

(ii) 

if  V  is  changed  to 

V' 

V 

(iii) 

Ri  ^  Qi 

(iv) 

if  is  changed  to 

additionally , 

Ql. 

(v) 

V.OQ^ 

Note  that 

(v)  implies  R  fl  W  = 

♦  . 

then  V[  C  V 

then  Q|  C  and  we  impose, 
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definition 


P^  conflicts  with  if 


W_.  ,  or 

++  Rj  ,  or 

W.  W.  . 
i  3 

Thus ,  we  now  allow  Ri  +-+  Rj  during  a  run  of  P^ 
and  Pj . 

notation  Let  Rj_  U  W£  be  denoted  by  RUW-^ ,  and 

\J  be  denoted  by  QUV^. 


Potential  Blocking 

definition  P_^ 


R 

W 


if  i  *  j 

i  Y 

.  QUVj . 


and 

or 


The  Safe  Situation 

The  definition  of  the  safe  situation  is  the  same  as  in  Section  I. 
Rules  of  Cooperation 

The  rules  of  cooperation  are  restated  as  follows : 

Rule  1:  Each  process  P  begins  operation  with  a  bound  V  on  its 

W  and  a  bound  0  on  its  R,  with  R  =  W  =  $ . 

Rule  2:  A  process  P  may  not  change  its  associated  R  or  W  if 

the  change  would  cause  it  to  conflict  with  some  other  process. 

Rule  3:  At  each  moment  of  time,  one  of  the  processes,  say  P,  takes 
an  action,  changing  its  state  in  one  of  four  ways: 


(1) 

P 

finishes ,  reducing 

R,  W,  Q,  and  V  to  the 

t  empty  set. 

(2) 

P 

changes  R  or  W, 

subject  to  R  C  Q  and 

w  c  v. 

(3) 

P 

changes  Q  to  Q* 

or  V  to  V1 ,  subject 

to 

Q' 

C=  Q  and  VT  (=  V. 

(4) 

R, 

W,  Q,  and  V  remain  unchanged. 

28 


Harmonious  Cooperation  in  (P,  j}) 


Theorem 


Proof : 


Theorem 


Proof : 


12  Let  P  change  its  state  according  to  Rule  3.  If  in 

the  new  state  P^  P,  then  this  was  true  in  the 
old  state  as  well. 

P-L  P  means  ++  V1  or 

Wi  ++  QUV1  ,  where  V1  and  Qf  are 
the  bounds  for  P  after  its  state  change. 

Suppose  that  Rj_  Vf  ;  then  3  r  e  R±  and  vf  e  Vf 
such  that  r  vf  .  But  v1  e  V  since  V1  cz  V  so 

that  R±  +-+  v  and  Pi  -►  P  in  the  old  state  as  well. 

Suppose  that  ++  QUVf  ;  then  3  w  e  VJ±  and 
sf  e  QUVf  such  that  w  s1.  Since  Qf  fl  Vf  =  <J> , 
we  have  sf  e  Q*  or  sf  e  V1  but  not  both.  If 
sf  £  Qf,  then  s'  e  Q  since  Q'c  Q  and  ++  Q. 
If  sf  e  V1 ,  then  sf  e  V  since  Vf  c  V  and 
R^  V.  In  either  case,  Ri  QUV  so  that 
Pi  ->•  P  in  the  old  state  as  well. 
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Assume  that  the  next  action  of  each  Pk  is  to 
increase  Rk  to  Qk  and  Wk  to  Vk  (i.e.,  make 
Rk  “  Qk  and  Wk  =  Vk) •  If  the  set  of  processes  is 
in  a  safe  situation  at  this  moment,  then  there 
exists  some  Pj  which  is  not  potentially  blocked 
by  any  other  process. 


Assume  the  theorem  is  false.  Then  for  every 
j  3  i(j)  such  that  P 


i(j) 


implies  R 


i(j) 

i(j) 


J 

V, 


at  this  moment 
or  W 


i(j) 


QUYj  . 


Suppose  Ri(j)  V4  ;  then  if  Pj  makes  Wj  =  Vj  , 

we  have  Ri(j)  Wj  ,  but  this  is  not  allowed  by  Rule  2. 


Suppose  that  Wi(j)  QUVj  ;  then  either  Wi(j)  Qj 
or  Wi(j)  Vj  .  If  Pj  makes  Rj  =  Qj  and 
Wj  =  Vj  ,  then  either  W^(j)  ++  Rj  or  Wi(j)  ++  Wj  , 
neither  of  which  is  allowed  by  Rule  2.  Therefore, 
we  have  that  Pj  may  not  take  its  next  action  because 
of  Rule  2.  But  this  is  true  for  all  the  processes. 
Since  no  process  may  take  its  next  action,  there  is 
no  time  tj  at  which  Pj  is  not  potentially  blocked 
(i.e.,  the  situation  is  not  safe). 
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The  rest  of  the  theorems,  corollaries,  and  lemmas  of  Section  I  are 
also  valid  here — they  need  not  be  proved  since  the  proofs  are  not 
affected  by  the  changes  we  have  made  in  our  definitions  and  rules. 

Discussion  of  (P,  P) 

If  we  allow  that  some  elements  of  S  be  identified  as  read-only 
elements,  then  we  may  relax  the  restrictions  on  the  processes.  In 
particular,  it  is  not  necessary  to  know  in  advance  that  a  read-only 
element  of  S  may  be  required  by  a  process,  and  a  process's  request 
for  a  read-only  element  may  always  be  honored  without  fear  of  deadlock; 
the  latter  statements  are  contingent,  of  course,  on  our  allowance  that 
for  any  i  and  j ,  i  ^  j ,  Ri  ++  Rj  is  always  allowed. 

In  the  model  we  have  defined,  the  more  difficult  problem  of  read¬ 
only  use  of  an  element  of  S  has  been  considered;  in  the  model, 
’’read-only"  is  treated  as  a  property  of  a  process  rather  than  as  a 
property  of  an  element  of  S. 


EXTENSION  TO  ALLOW  A  DYNAMICALLY  CHANGING  SET  P 
Introduction 


In  Section  I  we  considered  the  set  ¥_  to  be  a  fixed  finite  set 
of  processes.  Harmonious  cooperation  of  the  processes  was  explored 
for  a  single  run  of  the  system  (P_,  I))  in  the  sense  that 

a)  all  processes  in  P.  are  in  homing  position  to  start  (W  s  R  =  <J>) 

b)  when  a  process  takes  the  action  "finish,  reducing  W,  R,  V, 
and  W  to  the  empty  set,"  it  may  not  begin  another  run  until 
all  other  processes  have  also  finished;  and 

c)  when  all  the  processes  have  finished,  the  system  (P^,  D)  is 
again  in  homing  position,  at  which  time  another  run  of  the 
system  can  begin. 

In  this  section  we  allow  for  entering  and  leaving  processes  in 
the  set  P. 
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Cooperating  Processes 


We  allow  for  entering  and  leaving  of  processes  in  the  set  _P  in 
the  sense  that 

a)  a  process,  having  finished,  may  leave  the  system; 

b)  a  process  may  enter  the  system  at  a  moment  subsequent  to  the 
beginning  of  system  operation  and  may  become  engaged  after 
entering;  and 

c)  a  process,  having  finished,  may  become  engaged  again  at  any 
subsequent  moment. 

We  retain  the  conditions: 

1)  _P,  at  any  moment,  is  a  finite  set;  and 

2)  P  e  _P  is  a  process  in  the  sense  of  Section  I. 

We  relax  the  condition  that  the  system  returns  to  homing  position 
after  a  finite  amount  of  time  (makes  a  single  run) ;  rather,  we  have 
that  the  system  begins  operation  at  an  initial  state  (all  P  e  P_  in 
initial  state)  and  runs  for  an  indefinite  time. 

Let  us  extend  the  meaning  of  the  system  (_P,  _D)  as  above  and 
denote  the  extended  system  by  (_P,  D,  Ei)  .  Our  principal  objective 
will  be  to  prove  a  theorem  for  (_P,  D,  E]_)  analogous  to  Theorem  11 
for  the  system  (_P,  _D)  :  that  is,  we  want  to  show  that  every  process 
gets  to  finish  its  task  within  a  finite  amount  of  time  without  con¬ 
flicting  with  other  processes.  We  cannot  prove  such  a  theorem  at 
the  moment  for  by  E]^  we  have  introduced  the  possibility  of  permanent 
blocking;  it  becomes  necessary  to  examine  more  thoroughly  the  actions 
the  system  must  or  may  take  when  a  process  is  suspended  or  is  to  be 
restarted. 

Permanent  Blocking 

Permanent  blocking  is  a  condition  of  a  process  wherein  it  is 
blocked  by  the  states  of  the  system  for  an  indefinite  time  from 
acquiring  access  to  what  it  had  claimed.  While  the  system  (!P,  _D,  E^) 
may  remain  safe  from  deadlock  and  may  prevent  processes  from  conflicting, 
the  safe  situation  does  not  exist  if  some  process  is  permanently  blocked. 
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Permanent  blocking  arises  out  of  the  extension  ,  as  is  seen 
in  the  following  example.  Suppose  we  have  for  P_  =  {P]_,  P2,  P3}  that 
all  three  processes  make  an  indefinite  number  of  runs  and  that  for  each 
run  P]_  has  Vl  =  {a},  P2  has  V2  =  {b}  ,  and  P3  has  V3  =  {a,  b} . 
Then  the  system  may  get  into  the  situation  where  its  allocation  states 
permanently  block  P3  as  follows: 


a0  H  W1  =  {a}>  W2  =  *»  W3  =  * 

al  5  W1  =  {a}’  w2  =  -Cb> ,  w3  =  4> 

a2  5  W1  =  +  »  W2  =  {b}»  W3  =  * 

a3  H  =  {a},  W2  =  {b},  =  4> 

a4  E  a0‘ 


P3  is  permanently  blocked  if  it  has  requested  access  to  a  and  b, 
since  the  request  can  never  be  granted  without  causing  conflict. 

Notice  that  in  the  situation  described,  a  safe  situation  does  not 
exist  in  the  system  although  a  safe  permutation  exists  at  each  moment. 
We  have,  then,  that  a  safe  permutation  is  not  sufficient  to  guarantee 
the  safe  situation. 


Suspended  Processes  and  the  Scheduler 

In  order  to  deal  with  the  problem  of  permanent  blocking,  we 
formalize  the  notion  of  suspension  of  a  process. 

Let  £  =  {P|,  . P^.}  ,  k  <  n, 

be  the  set  of  suspended  processes  at  any  moment  in  the  system 
(P ,  D,  Ex) . 

We  postulate  the  existence  of  a  scheduler  in  CP,  D,  Ei)  which 
performs  management  services  for  the  processes.  The  scheduler 

1)  checks  safety  of  the  situation;  all  attempts  to  change  W 
(and  R)  are  made  through  the  scheduler; 

2)  suspends  a  process  when  a  request  for  a  data  element  (change 
to  W  or  R)  cannot  be  granted;  and 

3)  restarts  a  process  which  has  been  suspended. 
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With 

respect 

to  1)  : 

The  scheduler 

uses 

algorithm  a  (see 

page 

16) . 

With 

respect 

to  2)  : 

Let  ^  =  {Pi, 

p2 >  ■ 

»  .  .  ,  P£}  at  moment 

to# 

If 

at  moment  tQ 

+  1 

some  process,  say 

Pi, 

must 

be  suspended, 

then 

5.  =  {pi>  p$>  .... 

Pk> 

Pk+1> 

at  moment  tQ 

+  1, 

where  P£+l  =  ^i* 

In 

other  words,  the  queue  is  ordered  by  arrival;  a 
new  arrival  goes  to  the  end  of  the  queue. 

In  addition,  we  assume  that  the  scheduler  also 
remembers  a  process’s  request  when  it  suspends 
a  process. 

With  respect  to  3) :  We  have  not  said  under  what  conditions  a  process 

will  be  restarted,  whether  or  not  a  priority  is 
associated  with  a  process,  or  how  the  scheduler 
goes  about  deciding  that  conditions  are  right  for 
restart  of  a  particular  process.  In  fact,  we 
will  have  to  show  that,  by  some  scheduling 
algorithm,  a  process  will  remain  in  (£  for  only 
a  finite  time  (does  not  become  permanently 
blocked) . 

Scheduling  by  Expediency 

We  have  used  an  implied  scheduling  strategy  heretofore,  as  in 
the  recent  example  of  permanent  blocking  wherein  P3  never  gets 
access  to  what  it  had  claimed  (V  =  {a,  b}).  We  now  state  a  strategy 
explicitly  in  order  to  show  the  characteristic  of  permanent  blocking. 

Strategy : 

1)  every  request  for  a  state  change  involving  S  is  checked 

to  see  that  it  satisfies  Rule  2  and  Rule  3  (see  page  28)  and 
that  granting  the  request  would  result  in  a  safe  permutation; 

2)  whenever  such  a  state  change  is  requested  by  a  running  pro¬ 
cess,  the  scheduler  tries  first  to  honor  the  request  of  some 
P  in 

3)  ^  is  searched  in  order  of  entry  of  the  processes; 

4)  if  a  P  e  ^  is  found  whose  request  may  safely  (by  1)  be 
granted,  then  P  is  removed  from  (^,  its  request  is  granted, 
and  it  may  be  allowed  to  run;  the  running  process  which 
requested  the  state  change  enters  Q;  and 
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5)  if  ^  is  empty  or  no  P  e  ^  may  safely  be  granted  its 

request,  then  the  scheduler  proceeds  as  usual  (i.e.,  if  the 
request  may  safely  (by  1)  be  granted,  then  the  request  is 
honored;  otherwise,  the  requesting  P  enters  (£  and  some 
other  process  is  allowed  its  next  action) . 

(3) 

The  strategy  uses  the  expediency  condition,  which  is  to  grant 
a  request  if  the  grant  is  safe  as  defined  above.  The  strategy  does 
not  prevent  permanent  blocking;  the  example  given  recently  still  holds. 

In  the  example,  P3  is  permanently  blocked  because  it  can  never 
simultaneously  get  access  to  both  a  and  b.  This  suggests  that  the 
situation  might  be  improved  if  we  impose  the  condition  that  a  process 
may  request  only  one  element  of  S  per  request — this  would  impose 
upon  the  process  the  burden  of  collecting  all  the  elements  of  S  it 
needs  in  order  to  perform  some  processing  by  requesting  them  one  at 
a  time. 


Let  us  examine  the  example  given  previously  and  then  the  system 
in  general  with  this  condition  imposed.  We  had,  in  the  example, 


a2 

a3 

a4 


{a},  W2  =  <f>  ,  W3  =  <J> 
{a},  W2  =  {b},  W3  =  <j> 
<j>,  w2  =  {b},  w3  =  <j> 
{a},  W2  =  {b},  W3  =  <j> 


Suppose  now  that  P3  requests  a,  then  requests  b,  then  performs 
its  processing,  and  finally  releases  a  and  b  and  terminates. 

Then,  with  the  scheduling  strategy  we  have  defined,  a  possible  alloca¬ 
tion  sequence  is: 


ao 

al 

a2 

a3 

a4 

a5 

a6 

a7 


W, 


W, 


w. 


w. 


w. 


w. 


w. 


{a},  w2  =  ♦  ,  W3  =  <J> 
{a},  W2  =  {b},  W3  =  $ 


CNI 

J3 

il 

L  w3 

II 

-©» 

<J>  > 

W2 

=  (b 

},  w3 

=  b 

a} 

♦  . 

W2 

=  <K 

w3  = 

{a} 

W2 

=  ♦, 

W3  = 

(a, 

b} 

W2 

=  «{>» 

W3  = 

♦ 
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Thus,  no  process  is  permanently  blocked  in  this  example.  However, 
we  may  construct  an  example  in  which  P3  is  permanently  blocked  as 
follows.  Suppose  we  have  that  for  each  run 


P1 

has 

Vx  =  (a, 

c} ; 

P2 

has 

v2  =  {b, 

c} ;  and 

P3 

has 

V3  =  (a, 

b ,  c}  . 

If  it  happens  that  requests  only  a  during  its  run,  P2  requests 

only  b  during  its  run,  and  P3  happens  to  request  c  first  (before 
a  and  b) ,  then  the  system’s  allocation  states  may  permanently  block 
P3  as  follows : 


ao 

,  wx  = 

{a}, 

W2 

-  w3  - 

al 

,  Wl  = 

{a}  , 

W2 

=  {b},  W 

a2 

5  W,  = 

♦.  w 

2 

{b},  W3  < 

a3 

-=  wx  = 

{a}  , 

W2 

=  {b},  W 

a4 

H  a0. 

In  fact,  these  allocation  states 
sion  of  this  example.  At  no  tim 
c  because  we  would  have  either 


4) 

-  4> 

♦ 

=  + 

are  precisely  those  of  the  first  ver- 
:  may  P3  be  granted  its  request  for 


or 


P1  *  P3  *  P1 


p2  -  p3  -  Pr 


The  characteristic  of  permanent  blocking  is  that  a  process  is 
continually  held  up  because  advance  knowledge  of  the  constitution  of 
the  set  _P  is  not  available  and  no  special  action  has  been  taken  to 
force  an  allocation  state  which  will  free  the  process  from  suspension. 

We  will  next  consider  how  the  scheduler  may  take  special  action 
to  ensure  that  permanent  blocking  does  not  occur. 
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Scheduling  by  Eventuality 


We  will  consider  a  scheduling  strategy  wherein  the  eventuality 
condition^)  is  imposed — that  is,  we  will  allow  the  scheduler  to 
block  a  safe  request  for  a  finite  time  in  order  to  force  an  allocation 
state  which  relieves  permanent  blocking. 

To  this  end,  we  define  three  additional  sets;  E,  T_,  and  B_.  We 
will  use  _E  to  denote  the  collection  of  running  processes  and 
the  collection  of  new  processes  entering  the  system,  which  have  tem¬ 
porarily  been  blocked  by  the  scheduler  from  starting.  A  running  process 
is  one  which  has  been  engaged,  has  not  finished  the  run  for  which  it 
was  engaged,  and  is  not  currently  suspended  because  of  a  denied  request. 
(Note  that  in  a  multiprogramming  environment,  a  process  in  _E  may  be 
suspended  by  scheduling  action  related  to  the  multiprogramming,  but 
we  do  not  consider  that  here.)  is  the  queue  by  which  we  will  impose 

the  eventuality  condition.  B  is  a  special  set  which  will  always 
either  be  empty  or  will  contain  exactly  one  element  of  P_. 

We  have  then,  for  every  ?±  e  _P,  1  _<  i  _<  n,  Pi  e  E_  or  Pi  e  (£ 
or  e  T  or  P^  e  _B. 

£  E  means  P_^  is  running. 

P.  e  (£  means  is  suspended  awaiting  the  grant  of  a  request 

which  had  been  denied. 

Pi  e  T  means  P^  has  entered  the  system  subsequent  to  a  moment 
when  the  scheduler  decided  to  force  an  allocation  state  to 
relieve  permanent  blocking. 

Pi  £  B  means  P^  was  in  danger  of  being  permanently  blocked 
and  is  now  being  given  special  attention  by  the  scheduler. 

Define  the  function  q  as  follows: 


if 

X  = 

if 

X  * 

<t>, 

where  X  is  a  variable  which  may  have  the  values  _P,  E_y  T_,  B_. 
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We  now  state  a  scheduling  strategy,  wherein  we  retain  the  con¬ 
dition  that  only  one  element  of  S  per  request  be  allowed.  Strategy 
a: 

1)  Every  request  for  a  state  change  involving  S  is  checked  to 
see  that  it  satisfies  Rule  2  and  Rule  3  and  that  granting  of 
the  request  would  result  in  the  existence  of  a  safe  permutation 
of  the  processes;  when  these  conditions  are  satisfied,  we  say 
that  the  request  may  safely  be  granted. 


2)  For  P  e  E,  if  the  request  of  P  may  safely  be  granted, 
then  it  is  granted  and  P  remains  in  _E;  if  the  request  of 
P  may  not  safely  be  granted,  then  the  grant  is  not  made  and 
P  leaves  E^  and  enters 

3)  Whenever  an  element  of  S  is  released  by  a  process,  the 
scheduler  performs  the  algorithm  given  in  Figure  1  (next  page). 

4)  Whenever  a  process  say  Pa,  becomes  initially  engaged,  the 
scheduler  performs  the  following  algorithm: 


<START> 


Strategy  a  may  be  explained  by  intuitive  appeal.  When  a  process 
Pq  in  (£  is  found  which  had  requested  an  element  of  S  which  is 
now  available  but  the  request  cannot  now  safely  be  granted,  the 
scheduler  blocks  new  processes  from  acquiring  elements  of  S  in 
order  to  force  a  sequence  of  allocations  which  will  result  in  the 
removal  of  Pq  from  Q.  During  the  time  that  new  processes  are 
being  held  back,  the  other  processes  in  IS  U  Q  are  allowed  to  pro¬ 
ceed  under  the  expediency  condition — in  other  words,  processes  in 
(J  are  not  prevented  from  proceeding  whenever  they  can. 
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Figure  1.  Scheduler  Algorithm:  Release  of  an  Element 
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Harmonious  Cooperation  in  CE,  H,  El) 


Let  (P,  I),  Ei)  be  a  system  wherein  strategy  a  is  used  by  the 
scheduler.  Then  (_P,  I),  E^)  is  a  system  of  processes  which  harmoniously 
cooperate  in  the  processing  of  a  common  set  of  data.  We  show  this  in 
the  form  of 

Theorem  14  The  processes  of  the  system  (_P,  _D,  E^)  cooperate 

harmoniously. 

Proof :  It  is  clear  that  conflict  and  deadlock  do  not  occur 

and  that  at  each  moment  during  the  operation  of  the 
system  some  process  may  take  its  next  action.  We 
have  only  to  show  that  for  any  Pq  e  (£,  Pq  remains 
in  ^  for  a  finite  amount  of  time.  First,  we  show 
that  for  P^  e  (£,  Pj^  remains  in  for  a  finite 

time.  P^  e  (£  means  that  at  some  moment  P]^  requested 
sf  c  S  but  was  denied  grant  and  placed  in  (£. 

Either  sf  is  in  use  by  some  process,  or  it  is 
available  when  we  inspect  the  situation,  say  at 
moment  tj.  If  s'  is  in  use  at  t|,  then  within 
a  finite  time  it  becomes  available,  say  at  moment 
tj+k.  In  any  case,  within  a  finite  time  the 
scheduler  will  find  the  condition  Pj^  e  (£,  P|  had 
requested  sf,  and  sf  is  available.  If  it  is 
safe  to  grant  the  request  of  P| ,  then  Pj_  leaves 
(£  to  enter  IS.  If  it  is  not  safe,  then  the 
scheduler  inhibits  engagement  of  new  processes,  so 
that  Pj  leaves  ^  within  a  finite  time,  as  has 
previously  been  proved  in  Section  I. 

When  P|  leaves  (£,  P*>  becomes  P^,  etc.  Thus, 
for  any  Pq  e  Pq  remains  in  (£  for  a  finite 
amount  of  time.  Thus,  (P^,  I),  Ei)  is  a  system  of 
harmoniously  cooperating  processes  operating  on  a 
common  set  of  data. 
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SECTION  V 


A  REPRESENTATION  OF  THE  SYSTEM  (P,  D,  E^ 


INTRODUCTION 

In  this  section  we  develop  a  representation  of  (_P,  JD,  E-^)  which 

a)  shows  the  states  of  the  system  and  the  possible  transitions 
among  the  states, 

b)  describes  the  strategy,  a,  for  prevention  of  permanent 
blocking,  and 

c)  constitutes  a  partial  specification  for  a  simulation  of  the 
system. 


STATES  OF  A  PROCESS  IN  (P,  D,  E  ) 

We  describe  the  progress  of  a  process  through  the  system  {_P ,  _D,  E^)  , 
For  an  arbitrary  process,  Pa,  we  define  a  set  of  comprehensive, 
mutually  exclusive  states  as  follows: 


P  E  :  P  is  attempting  to  enter  the  system, 
a  a 

P  E^  :  P  e  _E-i.e.,  Pa  is  running  (subject  to  temporary  suspen- 
a  a  sion  due  to  multiprogramming) • 

P^Q  :  e  ^"“i*e.,  Pa  is  suspended  because  a  request  for  an 

element  of  S  could  not  safely  be  granted;  P 
is  waiting  to  get  its  request  and  continue. 


P  B  :  P  e  _B-i.e.,  Pa  is  getting  the  special  attention  of  the 

scheduler,  which  is  trying  to  force  an  allocation 

state  which  will  cause  the  transition  of  P  into 

state  P  E. 

a— 

P  T  :  P  e  T_-i.e.,  Pa  is  waiting  to  transition  into  state  P  E; 
this  will  happen  as  soon  as  B_  =  holds. 

P  L  :  P  has  terminated  and  leaves  the  system, 
a  a 


The  description  of  the  movement  of  Pa  through  the  system  and 
the  relationships  of  its  states  are  shown  in  Figure  2, 
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Figure  2.  Transition  Diagram  for  a  Process  in  CP,  J3,  E^) 
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The  description  of  Fig.  1  is  in  the  form  of  a  Petri  net^  for  the 
reason  that  the  transitions  are  more  explicit  (than  is  usual  in  state 
machine  representations) .  We  make  the  transitions  explicit  since 
most  of  the  transitions  of  Pa  are  contingent  on  the  holding  of  a 
set  of  propositions  about  the  system  in  general:  for  example, 

P  I  P  IS  is  contingent  on  the  truth  of  the  proposition  nB  =  <j>." 

In  Fig.  3  we  note  the  conditions  which  enable  the  transitions  among 

the  states  of  P  . 

a 

STATES  AND  BEHAVIOR  OF  THE  SYSTEM  (P,  £,  E  ) 

A  number  of  different  notational  schema  for  describing  the  states 
of  the  system,  its  behavior,  and  the  relationships  between  states  and 
actions  in  the  system  are  possible.  Two  formal  systems  are  of  parti¬ 
cular  interest  in  this  respect — Petri  nets^)  and  graph  programs. 

The  author  has  found  that  the  formalisms  and  intended  semantics  of 
these  systems  do  not  allow  for  the  easy  representation  of  states, 
state  transitions,  and  algorithms  in  one  descriptive  notation.  On 
the  one  hand,  a  Petri  net  provides  a  convenient  method  for  represen¬ 
tation  of  states  and  state  transitions;  on  the  other  hand,  a  graph 
program  is  a  convenient  way  to  represent  an  algorithm. 

Hence,  we  develop  in  this  subsection  a  specialized  notational 
schema  to  represent  both  the  states  and  the  behavior  of  the  system 
(P ,  D,  Ex) . 

We  define  a  function  c  as  follows:  c(X)  =  number  of  elements 
in  X,  where  X  has  the  domain  (P_,  E_,  C),  B_,  T} .  The  relation 

c(P)  =  c(E)  +  c(£)  +  c(B)  +  c(T) 

always  holds  in  the  system.  We  define  states  of  the  system  as  follows: 


SI: 

c(P) 

= 

0 

S2 : 

c(E) 

> 

0 

and 

c(T) 

= 

c 

(2)  = 

c(B)  =  0 

S3: 

c(E) 

> 

0 

and 

c(£) 

> 

0 

and 

c(T)  =  c(B)  = 

0 

S4 : 

c(E) 

> 

0 

and 

c(C>) 

> 

0 

and 

c(B)  =  1  and 

c(T)  =  0 

S5: 

c(E) 

> 

0 

and 

c(B) 

= 

1 

and 

c(2)  =  c(T)  = 

0 

S6: 

c(E) 

> 

0 

and 

c  (£) 

> 

0 

and 

c(T^)  >  0  and 

c(B)  =  1 

S7 : 

c(E) 

> 

0 

and 

c(T) 

> 

0 

and 

c(B)  =  1  and 

c(2)  =  0 
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SI  through  S7  are  a  set  of  alternatives  for  the  system — i.e., 
one  and  only  one  state  holds  at  any  given  moment.  The  possible  transi¬ 
tions  among  these  states  are  shown  in  Fig.  4,  which  is  annotated  with 
contingency  conditions  for  the  transitions. 

We  will  show  the  behavior  of  the  system  in  Fig.  5;  explanation  of 
the  notational  devices  and  some  additional  definitions  are  required 
first . 

Define  the  four  actions: 

Al:  a  process  enters  the  system. 

A2:  a  process  requests  loan  of  a  claimed  element  of  S. 

A3:  a  process  returns  to  the  system  an  element  of  S  it  had 

borrowed . 

A4 :  a  process  leaves  the  system. 

Define  notation  as  follows: 


denotes  a  state  of  the  system,  SX  domain  is  SI 
through  S7. 


denotes  a  transition  with  an  accompanying  action 
usually  noted. 


:  A  : 


x 


denotes  an  action  A1-A4. 


-FFR- 


used  as  a  line  connector;  has  no  other  meaning. 

denotes  that  one  and  only  one  of  the  multiple 
transitions  will  occur,  depending  on  conditions 
(to  be  noted) . 


:  when  two  or  more  arrows  arrive  at  a  transition, 

the  transition  occurs  when  and  only  when  source 
conditions  are  all  simultaneously  satisfied. 
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[Cl]  *.  A  PROCESS  ENTERS  THE  SYSTEM. 

[c 2]  :  C(E)  REDUCES  TO  ZERO. 

[c3]:  A  PROCESS  REQUEST  IS  DENIED  RESULTING  IN  C(Q)  *  0. 

[C4]:  AN  ELEMENT  OF  S  IS  RELEASED  AND  C(Q)  REDUCES  TO  ZERO. 

[C5]:  AN  ELEMENT  REQUESTED  BY  SOME  PcQ.  IS  RELEASED  BUT 
CANNOT  SAFELY  BE  GRANTED  TO  P. 

[C6]:  THE  ELEMENT  WANTED  BY  Pc  B  CAN  SAFELY  BE  GRANTED. 


Figure  4.  Transition  Diagram  for  States  in  (P^,  JD,  E^) 
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For  example: 
(  S3  ) 


in  this  example,  when  the  system  is  in  state  S3, 
it  will  transition  (either  1,  2,  3,  or  4) 
depending  on  which  action  occurs;  recall  that  in 
CP,  I),  E^)  one  and  only  one  of  the  actions  A1-A4 
may  occur  at  any  moment. 


(  )  :  statements  or  strings  of  symbols  enclosed  in 

parentheses  denote  actions  taken  by  the  system — 
the  action  symbols  are  defined  below. 


has  no  meaning;  is  a  shorthand  notation  for 


i 

i 

i 


1 


[  ]  :  statements  or  strings  of  symbols  enclosed  in 

brackets  denote  propositions  about  the  system; 
these  will  be  associated  with  transitions ,  a 
transition  occurring  only  when  its  associated 
proposition  is  true. 

For  example: 


lc(£)=0] 


l£(£)^0] 


in  this  example,  transition  1  occurs  if  Q  =  <f>  ; 
otherwise,  transition  2  occurs. 

note,  one  of  the  two  transitions  must  occur,  but 
only  one  will. 


Function  notations: 


+X 


means  add  a  member  to  the  set  X>  the  member 
is  determined  by  context : 

+X  =>  c(X)  c(X)  +  1 
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-X  :  as  for  +X  except  remove  instead  of  add  a  member: 

-X  =*>  c(X)  c(X)  -  1 

g(a)  :  means  make  a  loan  or  loans  to  the  process  a 

or  the  processes  in  the  set  a  for  which  the 
loan  is  safe. 

For  example: 

g(P^)  means  grant  the  request  (allocate  the  element  of  S)  to 

process  P,  . 

b 

g(Q)  means  grant  the  requests  of  any  members  of  Q  for  which 
the  granting  of  the  loan  is  safe,  any  such  member  is  to 
leave  (£  and  enter  IS,  and  the  size  of  (£  and  IS  are 
to  change  accordingly. 

Special  notation: 

will  denote  an  arbitrary  process;  when  used  in  context,  it 
indicates  the  process  of  the  context;  for  example: 

g(P^)  means  grant  the  request  of  the  process  which  has 
requested  an  element  of  S. 

P,  will  denote  that  process  P  for  which  it  is  true  that  either 
b 

P  e  (£,  the  element  s  requested  by  P  is  available  (in 

the  sense  that  conflict  would  not  exist  if  s  were 
allocated  to  P) ,  and  the  grant  of  s  to  P  is 
not  safe, 

or  P  e  13. 

S  :  denotes  the  statement  "grant  of  request  is  safe." 

NS  :  denotes  the  statement  "grant  of  request  is  not  safe." 

R(P)  :  denotes  "request  of  P." 

The  compounded  symbols  R(P)S  and  R(P)NS  have  their  obvious  meanings — 
"grant  of  the  request  of  P  is  safe"  and  "grant  of  the  request  of  P  is 
not  safe",  respectively. 
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Fig.  5,  a  description  of  the  behavior  of  the  system  CP,  JD,  E^)  , 
can  now  be  presented.  Although  it  is  equivalent  to  the  description 
of  the  previous  section,  it  has  the  distinct  advantage  over  the 
previous  description  that  it  exhaustively  shows  the  states  of  the 
system  and  all  possible  transitions  in  a  compact  form. 
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N4  DESCRIPTION  OF  SYSTEM  (P.D.EJ 
SHEET  I  OF  3 


Figure  5,  Description  of  the  Behavior  of  the  System  CP,  D,  E^) 
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N4.  (CONTINUED)  DESCRIPTION  OF  THE  SYSTEM  (P,D,  E,) 
SHEET  2  OF  3 


Figure  5.  (Continued) 
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N4 .  (CONTINUED)  DESCRIPTION  OF  THE  SYSTEM  (P,  D,  E 
SHEET  3  OF  3 

Figure  5.  (Concluded) 
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SECTION  VI 


THE  EXTENDED  MODEL  APPLIED  TO  A  SET  OF  COBOL  PROGRAMS 


INTRODUCTION 

In  this  section  we  consider  four  of  the  five  shortcomings  of  the 
system  (C9  _D)  discussed  in  Section  III.  We  will  not  deal  here  with 
units  of  lockout  other  than  the  file;  this  matter  is  reserved  for 
consideration  in  Section  VII.  We  will  consider: 

1)  a  dynamically  changing  set 

2)  multiple  concurrent  reading  of  the  same  file, 

3)  coordination  of  data  and  other  resource  sharing,  and 

4)  strategy  decisions  available  to  the  application  designer. 

As  background  to  these  four  considerations  we  will  discuss,  in  the 
next  sub-section,  the  general  requirements  imposed  upon  the  COBOL 
programs  by  the  extended  model  of  Section  IV. 


GENERAL  CONSIDERATIONS 

We  are  concerned  with  a  system  (C,  I),  E-^)  as  defined  in  Section 
III  and  naturally  extended  by  the  development  in  Section  IV. 

The  extension  to  include  differentiation  between  read-only  use 
and  other  use  of  a  file  implies  the  addition  of  a  declarative  state¬ 
ment  or  clause  to  some  section  of  the  COBOL  program.  This  declarative 
will  indicate  whether  the  program  will  use  a  file  in  read-only  mode 
or  otherwise.  A  convenient  place  to  include  such  a  declarative  clause 
would  be  in  the  SELECT  statement  of  the  FILE -CONTROL,  paragraph.  The 
compiler  of  the  COBOL  program  could  then  create  explicit  Q-list  and 
V-list  declarations  as  part  of  the  object  program. 

The  identification  of  files  as  read-only  files  might  also  be 
implemented.  We  do  not  consider  this  possibility  here  because  of  its 
triviality,  except  to  note  the  following.  Since  every  file  must  at 
some  time  be  created  and  may  at  times  require  updating,  the  system 
designer  must  take  some  precaution  that  during  creation  or  update  of 
a  read-only  file  conflict  and  deadlock  do  not  occur  and  must  also 
insure  that  the  updater  of  a  read-only  file  is  not  permanently  blocked 
by  an  unending  succession  of  readers  of  the  file. 
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The  constraint  mentioned  in  Section  III,  that  a  COBOL  program  may 
not  use  the  LINK  statement,  still  applies  in  a  restricted  sense.  There 
are  two  ways  in  which  the  LINK  statement  may  now  safely  be  used: 

1)  as  a  terminating  statement  of  a  program,  and 

3 

2)  as  a  CALL,  with  the  condition  that  the  CALLing  program  has 
declared  all  the  files  which  may  be  used  by  itself  and  all 
the  programs  which  may  be  activated  by  the  CALLing  LINK 
statement. 

1)  means  that  the  COBOL  program  closes  all  the  files  which  it 
had  opened;  in  executing  the  LINK  statement,  it  causes  two  things  to 
happen : 

1)  it  causes  itself  to  leave  (£,  I),  E^)  ,  and 

ii)  it  causes  the  LINKed-to  program  to  enter  (£,  I),  E^) . 

Restrictions  need  not  be  imposed  upon  the  passing  of  parameters  from 
one  to  the  other  of  the  LINKed  programs  except,  of  course,  the  acti¬ 
vated  program  could  not  attempt  to  open  a  file  whose  name  had  been 
given  as  a  parameter  if  that  file  had  not  been  declared  by  it. 

2)  means  that  the  collection  of  programs  including  the  one  which 
first  executes  the  LINK  statement  and  all  programs  subsequently 
activated  as  a  result  of  the  execution  of  that  LINK  statement  are 
essentially  to  be  considered  as  one  program  by  the  system.  In  this 
context  it  is  helpful  to  think  of  this  collection  of  programs  as  one 
process.  In  this  use  of  the  LINK  statement,  the  program  executing 

it  expects  control  to  be  returned  to  it  upon  completion  by  the  pro¬ 
gram  to  which  it  had  LINKed.  While  we  shall  not  formally  treat  such 
a  capability  here,  the  following  implementation  suggestions  may  be 
useful.  All  programs  could  be  partitioned  into  two  classes — process 
control  modules  (PCM)  and  process  modules  (PM).  The  imposition  of 
the  following  rules  should  suffice  to  avoid  problems: 

Rule  1:  file  and  other  resource  declarations  are  associated  only 
with  a  PCM. 

Rule  2:  a  PCM  may  not  call  another  PCM. 

Rule  3:  a  PCM  or  a  PM  may  call  any  other  PM. 

Rule  4:  a  PM  may  not  call  a  PCM. 


o 

In  this  case,  "process"  is  to  be  considered  a  collection  of  "COBOL 
object  programs." 


53 


This  method  is  also  applicable  in  the  discussion  of  Section  III. 

In  the  context  of  a  set  of  COBOL  programs,  the  restriction  imposed 
by  the  model  that  only  one  file  at  a  time  may  be  opened  is  no  restric¬ 
tion,  since  a  COBOL  program  may  open  only  one  file  at  a  time  anyway. 


DYNAMICALLY  CHANGING  SET  C 

In  Section  IV  we  have  shown  how  it  is  possible  to  allow  programs 
to  enter  and  leave  the  system.  We  proved  that  every  entering  program 
gets  access  to  all  the  files  it  had  declared  within  a  finite  amount  of 
time.  In  addition,  in  Section  V,  we  have  given  a  specification  of  an 
algorithm  to  be  used  by  the  scheduler  of  the  system. 


MULTIPLE  READ-ONLY  USE  OF  A  FILE 

Section  IV  dealt  directly  with  the  situation  that  a  number  of 
programs  may  concurrently  be  reading  the  same  file.  Under  GENERAL 
CONSIDERATIONS  of  this  section,  we  showed  how  the  intent  to  use  a 
file  in  read-only  mode  may  be  declared  by  a  COBOL  program. 


COORDINATION  OF  DATA  AND  OTHER  RESOURCE  SHARING 

Although  resource  sharing  in  general  is  not  a  principal  concern 
of  this  paper,  the  proper  coordination  of  resource  sharing  (other 
than  data)  with  the  data  sharing  methodology  presented  thus  far  is  a 
sine  qua  non  for  effectiveness  of  the  data  sharing  methodology.  If 
a  system  allows  resource  sharing  (in  addition  to  data  sharing) ,  say 
of  card  readers,  teletypes,  and  such,  then  the  possibility  of  dead¬ 
lock  arising  out  of  the  concurrent  use  of  such  resources  and  sets  of 
data  by  a  number  of  programs  must  be  considered  by  the  system  designer. 

To  see  that  a  problem  exists,  suppose  that  a  system  (£,  I),  E-^) 
uses  a  strategy  for  resource  sharing  which  guarantees  that  conflict, 
deadlock,  and  permanent  blocking  arising  out  of  the  use  of  the  resources 
will  not  occur.  Suppose  further  that  the  strategies  for  resource 
sharing  and  data  sharing  are  operated  independently  by  the  system — 
that  is,  when  a  request  for  the  opening  of  a  file  is  made  by  a  program, 
the  system  decides  whether  or  not  to  grant  the  request  without  consid¬ 
eration  of  the  allocation  state  of  the  system  with  respect  to  other 
resources,  and  vice  versa.  Then  deadlock  occurs  in  the  following 
situation.  Let  program  PI  have  allocated  to  it  resource  R1  and  file 
FI  and  P2  have  R2  and  F2;  let  PI  request  F2  and  have  its  request 
denied;  let  P2  request  R1  and  have  its  request  denied;  then  PI  and 
P2  wait  forever  while  the  system  ignorantly  proceeds  without  them, 
thinking  that  all  is  well. 
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The  solution  to  this  problem  for  a  given  system  depends  upon  the 
chosen  strategy  for  resource  sharing.  Presented  here, is  a  solution 
in  the  context  of  the  strategy  developed  by  Habermann.  » 1 '  An  exten¬ 
sion  of  that  strategy  is  required  in  order  to  prevent  permanent  block¬ 
ing  (see  Holt(^)).  The  system  designer  may  choose  to  use  Holt’s 
solution^)  to  accomplish  this  or  may  convince  himself  that  the  strategy 
developed  in  Section  IV  of  this  paper  will  also  serve.  In  any  case, 
coordination  of  data  and  resource  sharing  is  accomplished  simply 
through  the  safe  permutation  (sequence)  of  programs  by  requiring  that 
the  permutation  satisfy  both  the  requirements 


i)  (V  Pk  e  S) 


r(t) 


X!  £A(t) 

s(A)  £  s (k) 


(see  reference  (6),  page  375),  and 

ii)  for  each  P^,  k  e  {l,  2,  ...,  n-l) , 

P .  *V^P,  for  j  e  (k+1,  k+2,  ...,  n) 
J  ^ 

(see  Theorem  3,  Section  I). 


Caveat  emptorl  While  I  am  intuitively  convinced  that  the  solution 
offered  is  a  correct  one,  I  would  not  depend  on  intuition  alone  for 
the  design  of  a  real  system — rather  I  should  insist  on  a  rigorous 
description  and  proof  of  such  a  solution. 


STRATEGIES  FOR  THE  APPLICATION  DESIGNER 

The  hypothetical  system  design  developed  thus  far  does  not  allow 
strategy  decisions  by  the  application  programs  designer  sufficient  to 
adapt  it  to  a  reasonable  range  of  problem  structures.  On  the  contrary, 
unless  the  application  is  suited  to  the  supposed  system,  the  system 
must  be  considered  inadequate  in  spite  of  any  strategies  imposed  by 
the  application  programs  designer. 

Besides  the  strategy  of  separating  out  read-only-data,  the  appli¬ 
cation  designer  can  encourage  the  development  of  programs  which  keep 
non-read-only-use  files  open  for  as  short  a  time  as  possible;  the 
effect  would  be  to  keep  blocking  to  a  minimum.  However,  the  situation 
wherein  a  program  to  update  a  file  must  wait  until  all  other  users  of 
the  file  have  relinquished  use  of  it  cannot  be  escaped  by  strategy 
imposed  by  the  application  programs  designer. 
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The  latter,  inherent  characteristic  of  the  system  is  its  most 
serious  shortcoming — stated  another  way,  the  system  does  not  provide 
the  potential  to  achieve  effective  sharing  of  data  concurrently  unless 
the  data  are  static. 


SUMMARY 

As  we  have  seen,  the  model,  directly  applied  as  we  have  done  in 
this  section  and  Section  III,  produces  something  less  than  what  will 
satisfy  us. 

Good  purpose  will  be  served  by  reviewing  what  has  been  achieved 
thus  far.  We  have  done  the  basic  work  required  for  the  production  of 
a  real  system  which: 

1)  allows  multiple-user  data  base  sharing  (although  restricted 
as  we  have  seen) , 

2)  prevents  conflict,  deadlock,  and  permanent  blocking  among 
and  of  programs, 

3)  requires  only  slight  modification  to  an  existing,  familiar, 
applications  programming  language  (COBOL) , 

4)  guarantees  the  integrity  of  the  data  base  without  qualifica¬ 
tion,  and 

5)  guarantees  that  integrity  of  information  output  can  be 
achieved. 

The  fifth  point  deserves  some  exposition,  especially  because  it 
describes  a  property  of  a  system  which  we  might  be  willing  to  compro¬ 
mise  for  the  sake  of  achieving  some  other  goal.  What  "integrity  of 
information  output"  means  is  this — information  produced  by  a  program 
and  derived  solely  from  the  data  base  can  be  guaranteed  to  be  correct 
in  the  sense  that  the  data  extracted  from  the  data  base  were  semantically 
correct  at  the  time  of  extraction  (assuming  of  course  semantic  correct¬ 
ness  at  the  time  of  creation).  The  sense  of  this  guarantee  is  perhaps 
best  illustrated  by  a  negative  example.  Output  which  is  semantically 
incorrect  can  be  produced  simply  by  concatenation  of  data  elements 
which  are  anachronistic  with  respect  to  each  other;  many  familiar 
examples  will  suggest  themselves  to  the  reader.  Point  5  says  that  by 
appropriate  design  of  a  program,  it  can  be  guaranteed  that  such  loss 
of  information  integrity  will  not  occur. 
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If  we  agree  that  we  are  unwilling  to  compromise  the  properties 
suggested  by  points  1  through  5,  then  we  are  left  with  only  one  direc¬ 
tion  in  which  to  proceed.  Namely,  we  have  the  task  of  increasing  the 
potential  for  concurrent  use  of  the  data  base  without  giving  up  the 
desirable  properties  mentioned  above. 

One  method  suggests  itself — to  change  the  unit  of  lock-out  from 
the  file  to  the  record.4  A  moment’s  thought  of  this,  however,  will 
lead  to  the  conclusion  that  the  method  is  undesirable.  For,  consider 
what  it  would  mean:  one,  that  all  records  which  might  be  used  by  a 
program  would  somehow  have  to  be  declared  by  that  program;  two,  that 
upon  release  of  every  record  the  system  scheduler  would  have  to  go 
through  the  strategy  for  prevention  of  permanent  blocking;  three, 
that  the  scheduler  would  have  to  perform  the  safety  algorithm  every 
time  a  record  was  requested. 

A  seemingly  better  method  is  to  introduce  a  third  use-mode  for 
files  which  will  add  the  following  properties  to  the  system: 

1)  many  programs  may  operate  concurrently  on  the  same  file  in 

this  use-mode,  operation  to  include  changing  data  in  the  file;  and 

2)  the  application  designer  will  have  sufficient  strategy  latitude 
to  structure  sets  of  programs  which  can  perform  a  reasonable 
range  of  applications. 

In  the  next  section  we  extend  the  model  in  the  direction  we  have 
indicated . 


In  the  usual  COBOL  sense. 
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SECTION  VII 


EXTENSION  OF  THE  MODEL  TO  INCREASE  POTENTIAL  FOR  CONCURRENT  USE  OF  DATA 


INTRODUCTION 

In  this  section  we  define  a  third  use-mode  for  elements  of  S — 
inquiry-use-mode.  Rules  for  the  use  of  elements  of  S  by  processes 
of  in  this  mode  are  developed.  Finally,  as  for  the  extensions 

introduced  in  Section  IV,  we  show  harmonious  cooperation  among  the 
members  of  P. 


INQUIRY-USE-MODE 

We  have  previously  identified  two  use-modes  for  elements  of  S 
by  processes  in  P^: 

i)  read-use-mode,  and 

ii)  write-use-mode. 

Read-use-mode  allows  unrestricted  read-only  use  of  an  element  of  S 
concurrently  by  a  set  of  processes  in  _P;  write-use-mode  allows 
unrestricted  use  of  an  element  of  S  by  a  single  process  in  P_. 

Inquiry-use-mode  will  be  defined  to  allow  restricted  reading  and 
writing  of  an  element  of  S  concurrently  by  a  set  of  processes  in 
P. 


STRUCTURE  OF  THE  DATA 

The  structure  of  the  data  base,  D,  is  extended  as  follows. 
Let  each  element  of  S  be  a  finite  set  of  elements. 


notation  Small  Greek  letters  denote  elements  of  an  element 


of  S  5  e.  g .  ,  ot,  3,  Y,  •••• 

Since  the  elements  of  an  element  of  S,  say  a  e  S 
are  countable,  we  can  denote  a  e  S  by 


k 


i=l 
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definition 


definition 


remarks 


semantics 


where  k  is  the  cardinality  of  a;  the  ordering 
implied  by 


k 

i=l 


is  to  be  considered  arbitrary — we  wish  to  identify 
elements  of  a  not  to  order  them. 

JR1  will  denote  a  binary  relation  on  the  set 
VS  =  {a:  3a  e  S  such  that  ct  e  a} .  If  a  is 
jt'-related  to  g,  we  write  aRfg  . 


a  and  g  are  comparable  if  either  otR'g  or  gR/a. 
We  denote  this  situation  by  a  g. 


We  will  extend  the  concept  of  comparable  elements 
of  S  as  defined  in  Section  II.  If  a  and  b 
are  elements  of  S,  we  will  say  a  and  b  are 
comparable  if 

(i)  aRb; 

(ii)  bjta;  or 

(iii)  there  exist  a  e  a  and  g  e  b  such  that 

a  g . 

We  will  denote  this  situation  by  a  b. 


If  a  and  b  are  comparable  by  the  definition  in 
Section  II,  they  are  comparable  by  the  definition 
in  this  section.  Also,  if  a  z  a,  g  e  b,  and 
a  g,  then  a  -«->•  b  by  definition. 


The  motivation  for  the  introduction  of  finer 
structuring  of  I)  derives  from  the  discussion  of 
the  previous  section.  In  that  discussion,  a  z  S 
corresponds  to  a  COBOL  file,  a  e  a  corresponds 
to  a  record  of  the  file  a. 
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CONFLICT  AND  DEADLOCK 


Let  CP,  I),  E^,  denote  the  system  (_P,  I),  E^)  extended  as 

in  this  section. 

Let  each  P-£  have  associated  with  it  a  subset  Ii  of  S  at 
each  moment  of  its  engagement  and  let  Ji  denote  the  upper  bound  for 
Ii  for  a  run  of  Pi.  Ii  is  to  be  understood  to  contain  all  elements 
of  S  which  Pi  is  currently  using  in  inquiry-use-mode. 

We  have : 


ii) 

if  V± 

is 

changed 

to 

V!  ,  then  V'.  C  VJ 

1  1  —  i 

iii) 

Ri  —  Qi 

iv) 

if  ^i 

is 

changed 

to 

Q^,  then 

QI  -  Qi 

v) 

vi) 

if  Ji 

is 

changed 

to 

J ' ,  then 

Ji  —  Ji 

vii) 

Ji>  Vi’ 

Qi 

are  pairwise  disjoint 

( i  •  e  •  , 

Vi  0  Ji  “  Vi  0  Qi  =  Qi  0  Ji  =  <f>)  * 


Note  that  vii)  implies  that  Wi ,  Ri,  Ii  are  pairwise  disjoint.  Also, 
let  each  Pi  have  associated  with  it  a  set  Ki  during  each  moment 
of  its  engagement,  the  elements  of  which  are  those  elements  of  elements 
of  Ii  which  Pi  is  currently  using.  If  b  e  Ii  and  Pi  is 
using  S  £  b,  then  3  e  Ki. 


notation 


Let  UTVW.  . .  denote  T  U  V  U  W  .  .  .  for  any  subsets 
T,  V,  W,  .  .  .  of  S. 


definition 


P.  conflicts  with  P.  if 
1  -  j 

URWI,  W.  ,  or 

i  J 

W±  U  RWI  ,  or 


I. 

1 


V  or 

Y  or 


K.  ++  K. . 
1  J 
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The  relation  ++  Kj  means  is  using  some  element  a, 

and  Pj  is  using  some  element  g  such  that  a  g.  We  will  con¬ 
stitute  the  rules  of  behavior  for  the  processes  to  disallow  such  a 
situation;  we  must  also  formulate  the  rules  so  that  deadlock  is 
avoided.  We  have  allowed  that  I±  «->■  Ij  may  hold  during  a  concurrent 
run  of  Pi  and  Pj  .  This  means  we  are  allowing,  for  some  elements 
c  £  I|  and  d  e  Ij  such  that  c  d,  that  P^  and  P-j  may  con¬ 
currently  be  using  c  and  d,  respectively.  We  have  not  established 
an  upper  bound  for  the  set  K;  at  the  same  time  we  disallow  +-+  Kj  ; 

therefore,  we  must,  by  means  other  than  foreknowledge  of  a  bound  on 
K,  insure  that  deadlock  cannot  occur  because  of  inquiry-use-mode. 

To  provide  an  intuitive  justification  of  the  rules  to  be  proposed, 
consider  the  following  example  of  deadlock.  Let  P^  and  Pj  be 
engaged,  with  1^  and  Ij  non-empty.  Let  these  conditions  pertain: 

a  e  I 

b  e  L 
J 

a,  g  e  a 
A, 6  e  b 
a  ■<-*  6 
g  *-*■  A 
K£  =  {a} 

^  =  {A}. 

Then,  if  the  next  action  of  P^  is  to  change  to  {a,  g}  and 

the  next  action  of  Pj  is  to  change  K-j  to  {A,  6},  then  deadlock 
occurs  since  we  disallow  K-^  *<->*  Kj  ,  which  would  be  caused  by  either 
action  (since  a  «-*  6  and  g  ++  a)  .  Looking  at  an  earlier  time  in 
the  proceedings  of  P-^  and  Pj  ,  suppose  that  at  some  moment  t^ 
we  had  =  {a}  and  Kj  =  <f>  and  Pj  attempting  to  change  Kj  to 

{A}.  At  moment  t^  we  could  not  tell  whether  deadlock  would  occur 
as  a  result  of  allowing  Kj  =  {A}  since  no  upper  bound  for  K  is 
given;  at  the  same  time,  since  we  allow  1^  I j ,  the  possibility 

of  deadlock  always  exists  whenever  we  have  Ii  I  j  . 
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We  therefore  impose  the  rule  that  K  may  contain  only  one  ele¬ 
ment  at  a  time;  this  will  avoid  the  deadlock  of  the  previous  example, 
but  is  not  sufficient  in  general.  For  consider  the  following  example. 
Let  the  situation  be  as  in  the  previous  example  with  =  (a)  and 
Kj  =  {A}.  With  the  new  rule,  Pj  is  not  allowed  to  attempt  to  cause 
Kj  =  {A,  6},  nor  is  P-^  allowed  to  attempt  to  cause  Ki  =  {a,  3). 
Suppose  Pj  reduces  Kj  to  the  empty  set  and  then  attempts  to  cause 
Kj  =  {6};  since  a  6 ,  we  can  assume  that  Pj  will  be  queued, 
pending  (at  least)  reduction  of  Ki  to  the  empty  set  by  Pi.  However, 

suppose  that  the  next  action  of  Pi  (while  Ki  =  {a}  holds)  is  to 

request  some  element  v  e  Vi  such  that  v  w  e  Wj  ;  then  deadlock 
occurs  again  since  Pi  will  be  queued  because  of  its  request. 

Therefore,  impose  the  additional  rule  that  if  Ki  f  <(>,  then 
the  next  action  of  Pi  with  respect  to  E)  must  be  to  cause  Ki  ■  <f>. 

In  other  words,  for  any  Pi,  Pi  may  use  only  one  element  of  an  ele¬ 

ment  in  li  at  a  time  and  during  the  time  that  Pi  is  using  such  an 
element  it  may  not  request  the  use  of  any  other  elements  in  S. 


POTENTIAL  BLOCKING 

The  definition  of  potential  blocking  is  a  straightforward  exten¬ 
sion  of  the  definition  of  Section  III. 


definition  P .  P .  if  i  f  j  and 

-  1  J 

R.  ++  UJV.  or 

i  J 

Ii  UQVj  or 

W±  ++  UjQV^  • 

Note  that  the  notion  of  potential  blocking  does  not  include  any 
consideration  of  the  Kfs  associated  with  V±  and  P j .  This  means 

that  we  shall  have  to  concern  ourselves  with  the  explicit  proof  that, 
under  the  rules  of  cooperation  to  be  stated,  some  process  may  take  its 
next  action;  that  is,  it  no  longer  suffices  to  show  that  there  exists 
some  process  which  is  not  potentially  blocked  in  case  the  situation  is 
safe. 
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THE  SAFE  SITUATION 


The  definition  of  the  safe  situation  is  the  same  as  in  Section  II 
repeated  here  for  convenience. 


definition 


The  processes  of  P_  are  in  a  safe  situation  at 
moment  t  if  for  every  process  Pfc  the  moment 
tk  >  t  can  be  reached  at  which  the  relation  (1) 

Pj  — /■>  P^_  for  every  j  e  N  -  {1,  2,  .  .  .  ,  n)  holds, 


RULES  OF  COOPERATION 

The  rules  of  cooperation  are: 

Rule  1:  Each  process  P^  begins  operation  with 

a  bound  on  its  W-[, 

a  bound  on  its  Ri , 

a  bound  on  its  1^, 

Ii  =  Ri  =  Wi  =  Ki  =  4>. 

Rule  2:  A  process  P^  may  not  change  its  associated  UlRWK-^  if 

the  change  would  cause  it  to  conflict  with  some  other  process 

Rule  3:  At  each  moment  of  time,  one  of  the  processes,  say  P,  takes 
an  action,  changing  state  in  one  of  the  following  ways: 

(1)  P  finishes,  reducing  UlRWK  and  UjQV  to  the  empty 
set ; 

(2)  P  changes  UlRWK  subject  to 


i) 

I  c  J, 

ii) 

R  c  Q, 

iii) 

W  c  V, 

iv) 

I’  C  I,  R'  C  R,  and  W 

v) 

cardinality  of  the  set 

P  changes  UJQV  subject  to 

i) 

J’  C  J, 

ii) 

Q'  c  Q, 

iii) 

V’  c  V; 

(4)  UlRWK  and  U  JQV  remain  unchanged. 
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HARMONIOUS  COOPERATION  IN  (P,  D,  E  ,  E  ) 


Theorem 


Proof : 


15  Let  P  change  its  state  in  accordance  with  the 

rules  of  cooperation.  If  in  the  new  state  P-^  P , 
then  this  was  true  in  the  old  state  as  well. 

P^  P  means  R_^  U(JV)1  or 

Ii  -w  U(QV)  '  or 

W±  «-»■  U(JQV)  ’ 

where  (RST...)'  means  R'S'T'...  and  where  J', 

Q',  and  V'  are  the  bounds  for  P  after  its 
state  change. 

Case  1:  Suppose  Ri  U(JV)1  then  either 

R^  ++  J1  or 
R±  ++  V1 . 

Subcase  1:  Suppose  R^  J1.  Then, 

Ur  e  Ri,  j  e  J1  such  that 
r  j  r .  But  j  f  e  J  since 
Jf  c  j  so  that  R-£  J  and 
P^  -*  P  in  the  old  state  as  well. 

Subcase  2:  Suppose  R^  ++  VT .  Apply  same 
argument  as  for  subcase  1, 
resulting  in  P-£  P  in  the 
old  state. 

Case  2:  Suppose  l^J(QV)  1  .  Apply  same  argument 

as  for  Case  1. 

Case  3:  Suppose  U(JQV)f.  Apply  same  argument 

as  for  Case  1. 
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Theorem  16 

Assume  that  the  next  action  of  each  is  such  as 

to  result  in  *  Qk,  1^  =  J^,  =  V^.  If  the 

set  of  processes  is  in  a  safe  situation  at  this 
moment,  then  there  exists  some  Pj  which  is  not 
potentially  blocked  by  any  other  process. 

Proof : 

The  argument  is  the  same  as  for  Theorem  13. 

Theorem  17 

If  a  safe  permutation  of  the  processes  exists, 
then  the  situation  is  safe. 

Proof : 

Suppose  that  a  safe  permutation  exists.  Then  rela¬ 
tion  (2),  Pj  -h>  Pic  for  j  £  {k+1,  k+2,  ...,  n}, 
holds  for  each  k  e  N  =  {l,  2,  ...,  n}  and  for  P^ 
it  is  true  that  Pj  -/->  for  j  e  N.  By  Theorem 

15  and  Rule  3,  P^  may  complete  all  of  its  actions 

Theorem  15  guarantees  that  P^  cannot  become 
blocked  by  any  action  it  takes.  Also  P]_ 
cannot  conflict  with  any  other  process  except 
by  causing  Kj  for  some  i  e  N.  Sup¬ 

pose  that  at  some  moment  it  happens  that  an 
action  of  P^  would  result  in  for 

some  I  e  N.  Then  P^  cannot  proceed. 
However,  Rule  3  guarantees  that: 

i)  ?±'s  next  action  with  respect  to  I) 
can  only  be  to  cause  =  <f> ; 

ii)  P^  may  take  its  next  action  with 

respect  to  _D  since  ^  4>  implies 

that  ?±'s  last  request  was  granted, 

so  that  Pj_  has  not  been  queued 
pending  grant  of  a  request. 

Thus,  let  P-[  proceed  until  =  $  ;  at  this 

moment,  P]_  is  still  not  potentially  blocked 
since  the  action  of  P-£  could  not  cause 

P^  Pj,  and  P]^  may  take  its  next  action 

since  Kj  cannot  occur  for  any  j  e  N. 

Proceed  in  this  way  until  finishes,  say  at 

time  t1.  At  time  tf,  it  is  true  that  Pj  -/->  P2 

for  j  e  N.  Continuing  in  this  way,  we  find  that 

it  is  possible  to  reach  a  moment  t^  for  each  Pfc 
such  that  P  -/->  P^  for  every  j  c  N. 
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Theorem  17  does  not  prove  harmonious  cooperation  of  the  processes 
under  the  scheduling  strategy  developed  in  Section  IV,  since  in  the 
proof  of  Theorem  17  we  used  an  arbitrary  strategy  which  forced  a  state 
of  the  system  in  which  a  particular  process  could  proceed.  Theorem  17 
does  show  that  it  is  possible  for  every  process  to  proceed  to  comple¬ 
tion  of  its  run. 

We  wish  to  show  in  the  next  theorem  that  the  processes  cooperate 
harmoniously  with  the  new  rules,  operating  under  the  scheduling 
strategy  of  Section  IV. 


Theorem  18  Let  (P^,  ID,  Ei ,  E2)  be  a  system  wherein  strategy 

a  is  used  by  the  scheduler.  Then  (P_,  I),  El,  E2) 
is  a  system  of  processes  which  harmoniously  cooperate 
in  the  processing  of  a  common  set  of  data. 

Proof :  We  must  show  that  for  arbitrary  Pq  e  (£,  Pq  remains 

in  (£  for  a  finite  time.  First  we  show  that 
Pj  e  Q  remains  in  Q  for  a  finite  time.  First, 

P^  e  ^  implies  Kj_  =  <j>  so  that  P-[  cannot  cause 
entry  into  (£  of  a  process  which  attempts  to 
change  the  cardinality  of  its  associated  K  from 
0  to  1.  If  P|  entered  ^  for  the  reason  that  it 
had  attempted  an  action  other  than  change  to  , 
then  P-^  leaves  ^  in  a  finite  time  as  shown  in 
Section  IV  Theorem  14.  If  Pj[  entered  (£  for 
the  reason  that  it  had  attempted  to  change  cardinality 
of  K|  from  0  to  1,  then  3  Pe  e  E^  such  that  Ke 
contains  the  element  which  P|  had  requested. 

Since  Pe's  next  action  with  respect  to  ID  can 
only  be  to  cause  Ke  =  <t> ,  P|  leaves  upon 

release  of  the  element  in  Ke  by  Pe.  At  this 
moment  P^  becomes  P|,  and  so  forth. 
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SECTION  VIII 


THE  MODEL  (P,  D,  E  ,  E2)  APPLIED  TO  A  SET  OF  COBOL  PROGRAMS 
INTRODUCTION 

This  section  extends  the  discussion  of  Section  VI.  However, 
in  consideration  for  the  reader  who  may  wish  to  give  particular 
attention  to  the  system  of  cooperating  COBOL  programs  without  having 
to  labor  through  the  development  of  the  mathematical  model,  we  shall 
use  again  the  approach  used  in  Section  III.  That  is  to  say,  we  shall 
present  a  description  of  a  realization  of  the  mathematical  model  in 
terms  of  a  set  of  COBOL  programs,  restating  the  results  obtained  in 
narrative  form,  wherein  the  readers  intuitive  notions  replace  the 
formalisms  and  proofs  of  the  mathematical  model.  For  such  a  reader 
it  will  be  helpful  if  he  has  read  the  motivating  narrative  sections 
and  the  statements  of  the  theorems  in  the  discussions  of  the  mathe¬ 
matical  model.  The  reader  who  has  closely  followed  the  development 
of  the  model  may  wish  to  skip  ahead  to  the  DISCUSSION  OF  THE  SYSTEM 
(C,  I),  Ef,  E2)  on  page  75  of  this  section. 

STRUCTURE  OF  THE  DATA 

The  abstract  model  of  a  data  base  JD  =  (S,  R)  is  interpreted 
as  follows : 

Let  the  elements  of  S  =  {a,  b,  c,  d,  . . . ,  z)  represent  files 
in  the  COBOL  sense.  For  any  file  f  let  the  elements  of 

f  -  (rf  rf  f2>  #  #  *  9  rf  ,k^ 

represent  records  of  the  file  f  in  the  COBOL  sense.  Then  we  have 
the  simple  result  that  two  COBOL  files  f  and  g  are  comparable  if 

i)  f  =  g,  or 

ii)  there  is  some  record  in  f,  say  rf  f,  and  some  record 

in  g,  say  r  .,  such  that  rf  .  =  r 

g  >  J  * » i  g » J 

For  our  hypothetical  system  we  shall  assume  the  usual  COBOL  data 
structuring  so  that  condition  ii)  implies  condition  i) — that  is, 
files  are  either  identical  or  have  no  records  in  common. 
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COOPERATING  PROGRAMS 


We  shall  consider  a  "COBOL  object  program"  or  "a  set  of  COBOL 
object  programs"  as  discussed  in  Section  VI  (see  page  53)  to  be  a 
"process"  and  shall  simply  use  the  term  "program."  We  consider  the 
cooperation  of  a  finite  set  of  programs  operating  concurrently  on 
the  data  base  I)  =  (S,  =)  according  to  the  rules  of  cooperation  of 
the  model  (to  be  restated  later  in  this  section) .  Each  program  takes 
a  finite  number  of  actions  so  that  it  is  guaranteed  that  a  program, 
once  begun,  will  terminate  its  processing. 


USE  MODES  FOR  FILES 

Each  program,  at  the  inception  of  its  run,  declares  to  the  system 
its  intention  to  use  some  set  of  files  in  I)  (the  data  base)  .  Included 
with  the  declaration  of  the  file  name  is  a  declaration  of  intended 
mode  of  use.  (See  Section  III,  page  22,  and  Section  VI,  page  52  for 
a  discussion  of  how  these  intentions  might  be  included  in  the  COBOL 
program) . 

Available  to  the  program  are  three  modes  of  use: 


i)  write-mode, 

ii)  read-mode,  and 

iii)  inquiry-mode. 


These  modes  of  use  are  of  great  significance  to  the  data-sharing 
Scheduler  of  the  system:  they  provide  a  set  of  guidelines  used  by 
the  Scheduler  in  determining  which  requests  for  use  of  a  file  or 
record  may  be  granted  and  when.  From  the  point  of  view  of  the  COBOL 
programmer,  these  use  modes  have  the  following  meanings: 

i)  write-mode:  the  programmer  wants  exclusive  use  of  the 

file;  when  the  program  has  been  granted  access 
to  the  file,  no  other  program  will  be  granted 
access  to  the  file  until  the  program  declares 
that  it  is  finished  using  the  file  (CLOSES 
the  file) ; 

ii)  read-mode:  the  programmer  wishes  only  to  read  the  file  and 

is  therefore  willing  to  allow  other  programs 
besides  his  own  to  read  the  file  at  the  same 
time;  the  programs  must  not  change  the  file  in 
any  way; 
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iii)  inquiry-mode:  the  programmer  wishes  to  both  read  and  update 

records  of  the  file;  he  knows  that  the  records 
of  the  file  are  independent  in  the  sense  that 
it  is  sensible  to  change  only  one  record  at  a 
time;  he  is  willing  to  share  the  file  with 
other  users  so  long  as  they  obey  the  same 
rules  as  he  does;  moreover,  he  expects  (and 
the  Scheduler  will  guarantee)  that  no  other 
program  will  simultaneously  have  access  to 
the  same  record  as  his  program;  when  operating 
in  this  mode,  the  program  cannot  take  any 
action  on  the  data  base  except  to  relinquish 
use  of  a  record  of  an  inquiry-mode  file  once 
it  has  gained  access  to  that  record. 

For  a  given  program  we  shall  denote  the  set  of  files  it 

wishes  to  use  in  write-mode  by  the  notation  V-^ ,  the  set  of  files  it 
wishes  to  use  in  read-mode  by  Qi ,  and  the  set  of  files  it  wishes  to 
use  in  inquiry-mode  by  J± .  These  sets,  V± ,  Qi,  Ji  establish  the 
claim  set  for  C±.  Throughout  the  course  of  a  run  of  Ci  the 
Scheduler  will  keep  account  of  files  actually  in  use  by  Ci  with  a 
matched  set  of  sets  denoted  by  ,  R-£,  I-£  with  the  matching 


w. 

-  v. 

i 

i 

Ri 

- 

I . 

-  J  . 

i 

i 

For  example 

,  at  some 

moment 

during  a  run  of  Ci  we  might  have 

ii 

•H 

> 

{a,  b,  e} 

with 

W  =  {a,  b}, 

= 

{c,  f } 

with 

po 

p* 

II 

o 

Ji = 

id,  g) 

with 

I.  =  {d}. 

This  means  that  currently  has  access  to  the  files  a  and  b  in 

write-mode,  the  file  c  in  read-mode,  and  the  file  d  in  inquiry-mode 
and  that  it  had  declared  to  the  system  that  it  might  use  files  a,  b, 
and  e  in  write-mode,  files  c  and  f  in  read-mode,  and  files  d 
and  g  in  inquiry-mode. 
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CONFLICT,  DEADLOCK,  AND  PERMANENT  BLOCKING 


The  rules  of  cooperation  of  processes  and  the  rules  of  the  Scheduler 
developed  in  the  mathematical  model  of  the  preceding  sections  have  been 
formulated  to  avoid  tne  situations  which  we  shall  now  discuss. 

Two  programs,  C^  and  C j ,  conflict  if  they  are  both  using  the 
same  file  in  any  of  the  following  mode  pairs: 


c. 

1 

ci 

write 

write 

write 

read 

read 

write 

inquiry 

write 

write 

inquiry 

inquiry 

read 

read 

inquiry 

or  if  they  both  have  access  to  the  same  record  of  a  file  which  they 
are  both  using  in  inquiry-mode. ’  The  data-sharing  Scheduler  prevents 
conflict  by  denying  any  request  which  would  cause  conflict  if  the 
request  were  granted;  the  requesting  program  is  queued  and  will  auto¬ 
matically  be  unqueued  and  granted  access  as  soon  as  it  is  possible 
(in  the  mathematical  model  it  was  proved  that  this  occurs  within  a 
finite  amount  of  time) . 

Deadlock  is  the  situation  wherein  two  or  more  programs  mutually 
prevent  each  other  from  taking  their  next  actions  forever.  This 
would  happen  if,  for  example,  requested  access  to  b  and  Cj 

next  requested  access  to  g  while  the  situation: 

W  =  (g)  R.  =  (b } 

and  3 

V.  =  (g,  b}  Q  =  (g,  b} 

existed  because  the  Scheduler  would  queue  (because  Cj  is 

using  b  in  a  non-compatible  mode)  and  then  the  Scheduler  would 
queue  C-:  (because  has  use  of  g  in  a  non-compatible  mode)  . 

The  Scheduler  prevents  deadlock  by  not  allowing  the  potential  for 
such  a  situation — in  this  case  it  would  either  have  denied  use  of  g 

to  C,  or  use  of  b  to  C.. 

i  J 

Permanent  blocking  is  a  condition  wherein  a  program  is  indefinitely 
delayed  in  its  progress  because  of  a  sequence  of  allocation  states 
which  make  it  unsafe  at  any  moment  for  the  Scheduler  to  grant  a  request 
for  use  of  a  file  which  the  program  had  made.  The  Scheduler  prevents 
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permanent  blocking  by  detecting  the  possibility  of  such  a  sequence  of 
allocation  states  and  creating  a  situation  which  will  force  an  alloca¬ 
tion  state  wherein  it  is  safe  to  allow  the  potentially  indefinitely 
delayed  program  to  proceed. 

The  Scheduler  algorithms  are  given  in  Section  IV;  they  are 
trivially  extended  to  cover  inquiry-mode  by  the  rule  given  in 
Section  VII,  page  62.  In  the  previous  sections,  we  have  proved  that 
the  Scheduler  prevents  conflict,  deadlock,  and  permanent  blocking. 


THE  SAFE  SITUATION 

The  programs  of  the  system  are  in  a  safe  situation  at  some 
moment  if  every  program  can  have  simultaneous  access  to  all  of  the 
files  it  had  declared  in  its  claim  set  (V,  Q,  and  J)  within  a  finite 
amount  of  time.  The  rules  of  cooperation  and  the  data-sharing 
Scheduler  guarantee  that  the  programs  of  the  system  are  always  in  a 
safe  situation. 


RULES  OF  COOPERATION 


The  programs  must  operate  according  to  the  following  rules: 

Rule  1:  Each  program  C  begins  operation  with  an  established  claim 
set , 

V  -  the  set  of  files  it  might  use  in  write-mode 

Q  -  the  set  of  files  it  might  use  in  read-mode,  and 

J  -  the  set  of  files  it  might  use  in  inquiry-mode. 

At  inception  W  associated  with  V,  R  with  Q,  and  I 

with  J  are  established  and  are  initially  empty  (since  the 
program  has  not  yet  had  a  chance  to  OPEN  a  file). 


Rule  2:  A  program  may  not  OPEN  a  file  if  the  OPENing  would  cause  it 
to  conflict  with  some  other  program  (the  program  may  attempt 
to  do  so,  but  the  Scheduler  enforces  this  rule  and  queues 
the  program) . 

Rule  3:  With  respect  to  the  files  which  a  program  C  is  using  or 
might  use,  the  program  may  change  its  state  in  one  of  the 
following  ways: 

(1)  C  finishes,  relinquishing  its  hold  on  all  of  the  files 
it  was  using  or  might  have  used; 
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(2)  C  changes  W,  R,  or  I  by  opening  or  closing  a  file; 
it  may  open  any  file  listed  in  V,  Q,  or  J  or  it  may 
close  any  file  listed  in  W,  R,  or  I. 

(3)  C  acquires  access  to  a  record  of  a  file  which  it  has 
open  in  inquiry-mode  with  the  provision  that  no  other 
program  currently  has  access  to  the  record  and  its  next 
action  (with  respect  to  the  data  base)  will  be  to  return 
the  record  (relinquish  the  access  privilege) ;  it  need 
not  worry  whether  some  other  program  has  the  record — the 
Scheduler  enforces  the  rule  that  no  other  program 
simultaneously  have  access  to  the  same  record — in  case 
this  happens,  the  Scheduler  queues  the  requesting  program. 

(4)  C  changes  V,  Q,  or  J  by  declaring  to  the  Scheduler 
that  it  does  not  require  and  will  not  require  for  the 
rest  of  its  run  one  or  more  of  the  files  listed  in  V, 

Q,  and  J  (see  footnote  2,  page  24). 

ENTERING  AND  LEAVING  PROGRAMS 

There  are  no  problems  about  programs  entering  and  leaving  the 
system.  The  data-sharing  Scheduler  algorithms  and  the  rules  of 
cooperation  have  been  so  constructed  as  to  deal  specifically  with  this 
case.  Entering  programs  will  experience  delays  in  getting  started  in 
their  processing  only  when  the  Scheduler  is  attempting  to  force  an 
allocation  state  which  will  remove  the  potential  for  permanent  block¬ 
ing  of  some  program  which  is  already  in  the  system. 


CREATION  AND  DELETION  OF  FILES  AND  RECORDS 

Creation  and  deletion  of  a  file  are  not  problems  since  these 
actions  must  be  done  in  write-mode,  which  guarantees  exclusive  access. 
Record  creation  and  deletion  which  is  performed  in  write-mode  is 
clearly  no  problem.  The  questionable  case  is  creation  or  deletion 
of  a  record  in  inquiry-mode.  However,  since  only  one  program  at  a 
time  has  access  to  a  given  record  in  inquiry-mode,  again  there  is  no 
problem.  (Also,  see  related  discussion  concerning  indexes  to  random 
files  under  DISCUSSION  OF  THE  SYSTEM  (C,  D,  E][,  E2)  on  page  75.) 

Two  methods  of  implementation  for  handling  creation  and  deletion 
of  files  suggest  themselves.  One,  the  data-sharing  Scheduler  may  have 
a  static  information  base  which  covers  the  entire  universe  of  operation. 

In  this  method,  an  entry  exists  for  a  file  in  the  data-sharing  Scheduler's 
tables  whether  the  file  exists  or  not.  Two,  in  the  case  that  storage 
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space  is  very  limited,  the  Scheduler  could  dynamically  maintain  records 
of  which  files  exist — in  this  method,  perhaps  a  new  command  would  be 
added  to  the  system  to  inform  the  Scheduler  that  a  file  is  being  created 
or  deleted. 


THE  SCHEDULER 

We  present  in  narrative  form  the  principal  aspects  of  the  Scheduler’s 
operation  as  follows:^ 

1)  when  a  request  for  access  to  a  file  (by  OPEN)  is  made,  the 
Scheduler 

i)  checks  to  see  that  the  request  is  legal;  the  file  must 
have  been  declared  and  must  not  already  be  in  use  by 
the  requesting  program;  also  the  requesting  program 
must  not  currently  have  ownership  of  a  record  of  a 
file  which  it  is  using  in  inquiry-mode; 

ii)  checks  to  see  if  granting  the  request  would  cause  con¬ 
flict;  if  so,  the  requesting  program  is  queued;  if  not, 
then  the  next  step; 

iii)  checks  to  see  if  granting  the  request  would  result  in 

a  safe  permutation  of  the  processes;  if  so,  the  request 
is  granted  and  the  Scheduler  notes  that  the  requesting 
program  now  has  access  to  the  file  it  had  requested; 
if  not,  then  the  requesting  program  is  queued;  in 
either  case  the  request  has  been  processed  and  the 
Scheduler  is  done; 

2)  when  a  request  for  access  to  a  record  of  a  file  being  used 
in  inquiry-mode  is  made,  the  Scheduler 

i)  checks  to  see  that  the  request  is  legal;  the  file  must 
have  been  declared  for  inquiry-mode  and  the  program 
must  have  successfully  OPENed  it  and  the  program  must 
not  currently  have  ownership  of  any  other  record  of 
any  other  file  to  which  it  has  access  in  inquiry-mode; 

ii)  checks  for  conflict;  this  record  which  has  been  requested 
must  not  currently  be  owned  by  some  other  program;  if 
conflict,  then  the  Scheduler  queues  the  program;  if  not, 
the  request  is  granted  and  duly  noted  by  the  Scheduler; 


5  See  Section  V  for  a  more  formal  description. 
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3)  when  a  claim  set  establishment  request  is  received  from  a 
program  or  on  behalf  of  a  program,  the  Scheduler  updates  its 
tables  to  reflect  the  existence  of  the  program  in  the  system 
and  its  claim  set; 

4)  when  access  to  a  file  is  relinquished  by  a  program  (by  CLOSE) , 
the  Scheduler 

i)  checks  to  see  if  there  is  some  program  to  which  it  has 
given  priority  because  the  program  was  in  the  position 
where  it  might  have  been  permanently  blocked;  if  there 
is  such  a  program,  then  it  checks  to  see  whether  or 
not  it  is  safe  to  grant  that  program's  request;  if  it 
is  safe,  then  the  Scheduler  grants  access  to  the  file 
to  this  program,  notes  that  all  program  requests  may 
now  be  considered  (any  program  which  had  been  delayed 
in  starting  because  of  this  priority  program  are  now 
free  to  make  requests) ,  and  then  does  step  iii) ; 
otherwise,  the  Scheduler  does  step  ii) ; 

ii)  checks  to  see  if  any  queued  program  had  requested 
access  to  the  returned  file;  if  some  program  which 
had  been  queued  wants  access  to  the  file  which  has 
just  been  returned  but  the  grant  cannot  safely  be  made, 
then  the  Scheduler  gives  this  program  the  priority 
discussed  in  i)  and  notes  that  no  new  processes  may 
get  access  to  files  until  this  priority  program  has 
gained  access  to  the  file  which  it  had  requested;  then 
it  continues  at  step  iii) ; 

iii)  checks  to  see  if  any  queued  programs  can  now  safely  be 
granted  their  requests;  if  so,  it  grants  the  requests 
and  unqueues  the  programs;  then  it  does  step  iv) ; 

iv)  notes  that  the  program  which  gave  back  the  file  (did 
the  CLOSE)  no  longer  has  access  rights  to  the  file. 
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DISCUSSION  OF  THE  SYSTEM  ( C,  D,  E^  E2) 


Let  (C^,  JD,  E]_,  E2)  denote  the  system  of  COBOL  programs  described 
in  Section  VI  and  extended  according  to  the  development  of  Section  VII. 
Then  (_C,  I),  E^ ,  E2)  is  a  system  of  COBOL  programs  concurrently  and 
cooperatively  operating  on  a  common  set  of  files.  The  characteristic 
introduced  by  E2  is  the  capability  to  have  two  or  more  COBOL  pro¬ 
grams  concurrently  reading  and  ^pdating  the  same  file  or  files  under 
the  rules  for  inquiry-use-mode.  At  the  same  time,  the  system  retains 
the  properties  which  guarantee  that 

1)  conflict,  deadlock,  and  permanent  blocking  do  not  occur, 

2)  integrity  of  the  data  base  is  preserved,  and 

3)  integrity  of  information  output  can  be  achieved. 

However,  we  must  be  careful  to  understand  that  inquiry-use-mode 
represents  restricted  use  of  a  file.  The  extent  of  the  restriction 
will  depend  to  some  degree  upon  the  particular  implementation  chosen. 

In  order  to  explore  to  some  extent  the  nature  of  the  restriction, 
we  shall  further  construct  the  hypothetical  system  of  COBOL  programs 
and  then  consider  examples  of  operation. 

We  have  thus  far  assumed  that  each  file  declared  by  a  COBOL  pro¬ 
gram  (or  process)  would  have  associated  with  it  a  declaration  of 
intended  mode  of  use — read,  write,  or  inquiry.  Let  us  assume  fur¬ 
ther  that  an  implementation  of  the  model  is  carried  out  so  that  the 
resulting  system  has  also  the  properties  (taken  to  be  natural  ones 
by  direct  application  of  the  model)  now  to  be  discussed.  A  file 
declared  to  have  a  given  use  mode  may  only  be  used  by  the  declaring 
COBOL  program  (process)  in  that  use  mode.  Associated  with  each 
random  file  may  be  a  set  of  physically  separate  index  files.  An 
index  file  will  be  considered  to  be  a  collection  of  pairs,  each  pair 
consisting  of  a  key  and  a  pointer  to  a  record  in  the  random  file 
associated  with  the  index  file.  Now  let  us  suppose  further  that  no 
provision  has  been  made  for  declaring  use  mode  for  an  index  file; 
rather,  when  a  random  file  is  declared,  an  associated  set  of  index 
files  is  also  declared  and  the  use  mode  of  the  index  file  is  inexorably 
decided  by  the  system. 

If  the  file  is  declared  with  use  mode  read  or  inquiry,  then  the 
associated  index  files  have  use  mode  read;  if  the  file  has  use  mode 
write,  then  the  associated  index  files  have  use  mode  write.  We  can 
now  consider  some  examples  involving  inquiry-use-mode. 


In  this  mode,  an  a  (element  of  an  element  of  S)  corresponds  to  a 
COBOL  record. 
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Suppose  that  a  random  file,  say  r,  with  one  associated  index, 
say  i,  is  used  in  inquiry-use-mode  by  several  COBOL  programs.  With 
the  assumed  implementation,  while  it  is  true  that  records  of  the 
file  may  be  read  and  updated  by  the  several  COBOL  programs,  it  is 
not  true  that  updating  of  a  record  in  r  can  be  allowed  to  affect 
the  index  i — in  particular,  a  record  may  be  neither  created  nor 
deleted  in  inquiry-use-mode.  Hence,  changes  to  the  index  i  must 
be  done  in  write-mode  (exclusive  owner) . 

With  such  an  implementation  assumed,  we  can  readily  deduce  char¬ 
acteristics  of  operation  of  the  system.  Clearly,  an  application 
wherein  only  inquiry-use-mode  is  normally  required  can  be  handled 
effectively.  If  the  application  naturally  allows  for  a  cycle  of 
operation  in  which  the  modes  of  operation  alternate  between  inquiry- 
use  and  reporting/updating,  then  the  model  seems  readily  adaptable 
to  the  design  of  a  system  for  the  application.  However,  suppose 
that  an  application  requires 

1)  inquiry-use-mode  predominantly,  and 

2)  occasional  updates  which  cannot  be  batched. 

An  example  of  such  an  application  is  an  on-line  banking  application 
viewed  during  the  hours  when  the  bank  is  servicing  customers.  Let 
r  represent  a  customer  checking  account  file  and  let  i  represent 
an  index  to  the  random  file  r,  where  the  index  key  is  account  num¬ 
ber.  Imagine  r  being  used  in  inquiry-mode  by  a  number  of  tellers 
while  r  is  occasionally  used  by  branch  managers  in  write-mode  to 
add  and  delete  customers  (affecting  i,  naturally).  Further  assume 
that  it  is  normal  practice  for  a  teller’s  program  to  open  the  file 
r  at  the  beginning  of  the  teller’s  hours  and  not  to  close  it  until 
the  teller  is  ready  to  terminate  his  service  (otherwise,  an  open  and 
close  would  be  done  for  each  transaction,  thereby  defeating  the  use¬ 
fulness  of  inquiry-use-mode).  Then  we  have  the  disappointing  result 
that  an  attempt  at  9  a.m.  by  a  branch  manager  to  add  a  new  customer 
to  the  file  will  probably  not  succeed  until  around  4  p.m.  of  the  same 
day  (since  we  call  W  I  a  case  of  conflict  and  disallow  it) . 

The  ingenuity  of  the  system  designer  and  knowledge  of  the  appli¬ 
cation  can  both  come  to  the  rescue  in  this  case.  We  can  easily  extend 
an  access  privilege  to  the  branch  managers,  who,  operating  in  good 
faith,  temporarily  are  allowed  write-use  access  to  r  (one  at  a  time 
naturally)  even  though  r  is  currently  open  for  a  number  of  inquiry¬ 
mode  users.  The  good  faith  part  is  this  -  that  the  COBOL  program 
being  run  by  the  branch  manager  from  his  terminal  does  not  attempt  to 
open  other  files  after  opening  r  for  update.  Of  course,  allowing 
this  program  to  update  the  file  r  will  block  out  all  inquiry-mode 
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users.  However,  if  the  business  of  the  branch  manager  is  to  open  the 
file,  add  or  delete  a  customer,  and  close  the  file,  then  we  are 
dealing  with  a  delay  at  a  teller’s  terminal  of  only  seconds.  Moreover, 
the  system  designer  can  easily  convince  himself  that  such  an  access 
exception  does  not  undermine  the  correct  operation  of  the  system; 
he  must  provide,  however,  that  access  to  i  followed  by  access  to 
r  be  considered  an  indivisible  operation  in  inquiry-use-mode  for 
certain  types  of  structure  for  i  such  as  hash-encoding. 


SUMMARY 


The  foregoing  discussion  shows  that  the  model  is  not  a  set  of 
sacrosanct  rules  for  the  implementation  of  a  system;  the  proper  use 
of  a  model  is  to  guide  an  implementation  to  the  production  of  a  cor¬ 
rect  and  effective  system.  For  example,  while  Theorem  18  of  Section 
VII  shows  that  the  strategy  developed  in  Section  IV  will  work,  prac¬ 
tical  considerations  suggest  that  a  separate  queue,  say  _I,  for  pro¬ 
grams  suspended  by  an  inquiry-use-mode  request  will  reduce  the  amount 
of  work  performed  by  the  scheduler — for  the  scheduler  need  then  inspect 
_I  only  when  an  element  which  had  been  requested  by  a  program  in  I_ 
is  released  and  need  never  inspect  when  an  inquiry-use-mode  record 

is  released. 

With  the  addition  of  E2  to  the  system  of  COBOL  programs,  we 
have  greatly  extended  the  flexibility  with  which  the  application 
designer  may  approach  his  job.  As  we  have  seen,  implementation  stra¬ 
tegies  and  adaptations  of  the  model  can  add  to  this  flexibility. 

The  application  designer,  by  appropriate  implementation,  is 
given  these  tools: 

1)  an  application  language,  COBOL; 

2)  a  data  base  structure;  and 

3)  three  use-modes  for  programs  operating  on  the  data  base. 

The  system  within  which  the  application  designer  must  work  is  suited 
to  those  applications  wherein: 

1)  the  organization  of  the  data  base  can  be  planned  ahead  of 
implementation;  and 
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2)  the  functional  requirements  are  known  ahead  of  implementation 
so  that  each  COBOL  program  can  be  tailored  to  do  its  job 
with  minimum  effect  on  other  programs  in  the  system. 
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